Add command displaying recommended light client's trust for the state sync

[martintomazic]

Motivation:
The process of finding correct light client trust needed for the consensus state sync is manual and tedious.

Feature request:
Add a new command to the oasis cli that displays appropriate light client trust.

Context:

1. Light client trust period must be lower than debonding period (336 epoch, ~2 weeks) to prevent long range attacks.
2. Checkpointing frequency is defined by the consensus parameters and currently happens 1/week.
   • I.e. unless manually modified all nodes create checkpoints at the same heights.
3. Node does a state sync by first requesting available checkpoints from its peers. To prevent spam, it first validates advertised checkpoint and the corresponding root by comparing it to the light client root at a given height.

As a consequence, one must configure sufficiently old light client trust (height, hash and period), so that there will be corresponding light client header available for at least one checkpoint advertised by the p2p network. Finally, trust period must be be longer than the age of configured trusted header, else a checkpoint that happened recently would fall out of trust period interval.

Proposed solution:
Query consensus parameters (debonding period, block frequency, checkpoint interval). Calculate appropriate trusted period and trusted height. Finally, query block header for the trusted height (trusted hash).

For the current set of parameters, I would expect this command to return trust period of ~12 days, and trusted height that is ~10 days old.

Alternative solution:
Less optimal, once oasisprotocol/oasis-core#5823 is merged you will be able to query node's local checkpoint heights from the status. In case node is not creating checkpoints we could add a separate method to the node that queries checkpoints using its p2p client. This seems quite a lot of work for smtg that can be done simpler.

[martintomazic]

Update: The nodes didn't have pruning enabled but instead they had very little history due to a recent state sync. So take everything below as not 100% correct. However, this exposes that this command may have corner cases, i.e. we cannot expect it to work 100% of time.

Proposed solution has an issue that public nodes that the cli connects to by default prune everything that is older than 6 days. However, you need information about the block that is at least as old the the checkpoint interval (so 7 at minimum, ideally more).

There is another minor issue: when you calculate average block speed (you have to assume it is stable). This is not best since if block speed changes, or if the network halts for a long period this calculation would then be off. Not critical as we can always sanity check and error...

Alternative solution has an issue that if remote nodes don't produce checkpoints (default fallback of cli) then you gain no information + again is limited by the pruning -> last retained height.

As for more cumbersome solution of finding heights from the p2p network if not available locally, again this won't work with public grpc in cases the latest checkpoint height is older than last retained height.

In short the ux impact of this feature might be lower that we want: I.e. we can make it work only for people that manually point cli to the node that keeps more then a week of data. Unfortunately, most people fall out of this category. Regardless, I think this feature is useful and we should proceed?