📚 Plan validator onboarding flow and create guideline

[hacheigriega]

📚 Documentation

The validator onboarding process now has an additional component of batching key generation and registration.

The most straightforward flow would be:

1. If we are upgrading an existing chain, first perform an upgrade to the new binary version that contains the batching feature.
2. The parameter for vote extension enable height is set at some height H in the future.
3. The validators are asked to use the add-keys transaction to generate and register the required keys before H is reached.
4. If more than 2/3 of validators have fulfilled the task, the batching is enabled successfully. If not, the chain halts.

To avoid the possibility of chain halt, we could take the following steps instead:

1. If we are upgrading an existing chain, first perform an upgrade to the new binary version that contains the batching feature.
2. Add a boolean state IsBatchingEnabled for indicating whether batching has been enabled or not. Its initial value is false, and, once switched to true, it will never revert to false. The voting power check in PrepareProposal and ProcessProposal are disabled until the voting power of the votes with extensions reach 2/3, at which point IsBatchingEnabled is switched to true and the voting power check is enabled.

This way, the batching sequence is enabled at whichever height more than 2/3 of validators have generated and registered the SEDA keys.

[Thomasvdam]

I feel like the technical work has been completed with #412 and #422. Do we want to use this issue to track updating the docs to explain this new key, the changes to the create validator command, and explaining the activation of a proving scheme?

[Thomasvdam]

We should include documentation on how to handle Horcrux (or similar) setups, as well as details on the SEDA key file, encryption of said file, and all related SEDA node and TX options. See #415 and #468