docs/Run your node: Update hardware requirements

[martintomazic]

Update the current hardware requirements, specifically storage.

Currently, they portray impression that running a Consensus + Sapphire node (Validator + Compute node) requires 2TB of the disk space. This are hardware requirements for nodes that are able to serve all historical state... Serving historical state is NOT validators responsibility.

Instead they should have pruning set to few weeks max - see #1526. This makes them fast, enables checkpoint creation that is quick and has little IO overhead, resulting in a much smaller disk footprint, and thus cost. E.g. 100GB should be enough.

Finally, we should organize Run your node sections from most to least accessible options. E.g. hardware requirements should reflect this order:

1. Stateless
2. Non-Validator/Paratime-Client (with pruning)
3. Validator/Executor (with pruning)
4. Observer (with pruning)
5. Non-Validator/Paratime-Client/Observer with all historical state.
6. Keymanager/Sentry/Archive

Partially overlaps with #1469.

[amela]

Thx for the ideas.

[martintomazic]

Finally, we should organize Run your node sections from most to least accessible options. E.g. hardware requirements should reflect this order:

If we decide for such reorg, it would be nice to avoid the pattern of the partial configurations, that reference 3 other chapters, in order to augment the config. I understand we don't want to repeat snippets, but this unfortunately results in the very bad UX for the end user.

Depending on the role/use case (that should have a dedicated section), I want to directly copy the whole config. The only thing I expect to edit are $VAR_NAME in the config. For those we could have how to guides (e.g. pruning, trust root etc...), that could be further split per role. E.g. setting trust root for stateless client is different then setting it for the paratime client node.

If we decide to proceed with this, "the new organization" is actually a separate issue than the "update hardware requirements". Just idea, priority low, won't be working on this anytime soon. :)