Horizon upgrade best practices

[sreuland]

What problem does your feature solve?

No copy present in current docs https://developers.stellar.org/docs/run-api-server/ for how to upgrade a recent installed horizon to newer version. There is copy on migrating from 1.x which is obsolete now?

What would you like to see?

• Rename Migrating from 1.x menu to be 'Upgrade', and repurpose the right hand side page content:
  • How does user verify if state rebuilds will be triggered?
  • How does user know if database schema upgrades will be triggered and for how long?
    • Changelog usually mentions if db schema changed and expected duration of the new migrations step added ...
    • What mechanisms or cli tricks are available to check if a schema migration will be triggered from current to new?
      • install new horizon on a machine that has access to db, don't start it, just run horizon db migrate status ... what else is better to do here?
  • Describe how db schema migration is invoked automatically by horizon at start up, are there any command line flags that affect or related to this upgrade behavior? I.e. if ingest=false, it skips attempting schema upgrades and just starts web server.
  • What are recommended pre-upgrade steps:
    • determine if a new version of horizon will trigger a schema update
    • back up db
    • multi-instance deployment considerations, rolling upgrades, if helm this is managed.

What alternatives are there?

[sreuland]

PR's should be targeted to https://github.com/stellar/stellar-docs/tree/partner_experience feature branch, all the partner experience tickets will accrue on that feature branch first.

[sreuland]

merged #241