Perform migrations on start up

[gracenoah]

Stellar core automatically migrates its database on start up if it's not migrated yet and there's no way to control that behaviour. I think that this image should also do the same unconditionally because:

1. It wouldn't make it any less flexible than stellar core and everyone running horizon must also deal with stellar core's limitations
2. It would make the behaviour consistent and avoid requiring manual intervention during database upgrades.

I'd also be happy to have this configurable via an environment variable. Same for core, but it would require a code change for core. See stellar/stellar-core#1912

[gracenoah]

I worked around this for now by setting the entrypoint to:

["/entry.sh", "sh", "-c", "horizon db migrate up && exec horizon"]

[andrenarchy]

I'm using an explicit migration job in Kubernetes at the moment but this is not ideal – it's also not consistent with the db initialization. I think making both the db initialization and the migration configurable with an env var makes most sense.

@gracenoah What do you think?

[gracenoah]

If you want to make the behaviour configurable, then I'm happy with that. Then everyone can do migrations however they want. Running migrations / initialization separately is obviously the right thing to do if you want to enforce least privilege and have a separate database user for the migrations vs running instance, but we've lowered our standards to the lowest common denominator for stellar because of core's behaviour, so at least I'll be running migrations automatically.

[andrenarchy]

I think it'd also solve the issue you fixed with #11 – if you explicitly tell it to initialize the database and it fails (either because it already exists or because the connection fails) then the container just won't start. Does that make sense?

[gracenoah]

I'm not following. Initialization is different from migration. Initialization is always expected to fail on startup except the first time. Migration is always expected to succeed on startup.

There are generally 2 desired modes for the management of the db:

1. Do whatever is necessary to initialize or migrate and then start
2. Do no initialization/migration and start

We use the former but the latter is also very useful to have for more complex deployments.

The split of initialization vs migration is not very useful, but that's just what horizon does, so I'm fine with having 2 flags.