Dump validators list from oasisscan and use as fallback

[lukaw3d]

Part of #751
Part of #749

Currently, oasisscan is down, and oasismonitor is not loading validators.

Before	After

[tjanez]

I like this approach. I would perhaps just add a general notification like "Showing validator list as of <DATE-AND-TIME>".

Update: Could we tune the text to not show

Validators

Couldn't load validators. List may be empty or out of date. Error: request https://monitor.oasis.dev/data/validators?limit=500 status 500

but something like:

Validators (last updated: <DATE-AND-TIME>)

Error obtaining validator list from Oasis Monitor: request https://monitor.oasis.dev/data/validators?limit=500 returned status 500.

If everything works, it could just show:

Validators

But that can be done in a follow-up PR.

[Yawning]

So with this users can end up delegating to a stale validator that may no longer exist? At a minimum staking operations while this data is being provided to users should be limited to debonding.

NACK.

[tjanez]

Fair point, agreed

[lukaw3d]

Mitigated by marking them all inactive for now, but I don't intend to merge

[buberdds]

imo instead of changing initial state we should fallback in saga when a request fails. instead of dispatching updateValidatorsError action we can dispatch
yield* put(stakingActions.updateValidators(validatorsDump.validators))

[lukaw3d]

One difference in that case (without extra handling): if getting validators first succeeds, but fails second time, result is:

• fallback on error: fallback
• fallback in initial state: first success

[buberdds]

ah true, is it possible that between the first and the second request validator could be updated? First success -> validator A works just fine -> something bad happens to validator A -> the second request to monitor fails -> we show fallback in initial state: first success where validator A is Ok -> user delegates to a stale validator.

[lukaw3d]

Yeah, it is possible

[lukaw3d]

Added a warning before staking to validators with status inactive* or unknown:

---

* Active/inactive meaning oasisscan/swagger.yml#L306-L309:

If "true", an entity has a node that is registered for being a validator, node is up to date, and has successfully registered itself. However, it may or may not be part of validator set (top <scheduler.params.max_validators> by stake).

[Yawning]

While the warning does make things clearer, I am still torn on this because it still forces people that delegate to something not working, into the debonding period. I am still of the opinion that instead of a warning this should just flat out reject the operation.

Inevitably someone will ignore the warning, and later complain once their tokens get stuck in debonding. While it is on them, forcing people to wait till things recover (in what should be an increasingly rare occurence in the future), is likely better.

If people really can't wait to delegate the command line tools will always work...

[lukaw3d]

Another issue: this list is inaccurate for testnet

Disabled confirm button