At present, managing Tendermint storage is unnecessarily complex and sometimes confusing. We have many configuration options that impact storage (some of which need to be configured by the application) and it's not clearly documented as to the impact of all of those configuration options. We should investigate options for simplifying that experience for operators.

• Improve the documentation around the impact of using different storage-related options
• Decide on whether an alternative UX strategy should be implemented for operators
  • Option: operators define one overall maximum storage limit for the node, and let the node automatically prune non-critical data to try to keep to that target. Questions remain though around this strategy, such as:
    • Can we separate each type of data stored by a Tendermint node into a different "category", ranked by criticality?
    • What are the different "levels" of criticality that we should support?
    • Should data category criticality be able to be controlled by operators?
    • What does a Tendermint node do when it cannot prevent itself going over the storage limit? (by way of the criticality configuration, if there is a level that can never be pruned)

Original issue: tendermint/tendermint#9906