Simplified version of multiple apps deployment

[mzabani]

The idea here is to do an extremely simplified version of #47. The requirements are:

• No new commands or configuration necessary
• Not necessary to have any kind of coordination, except ensuring no migrations run twice and all pending migrations run in order.

One idea here is to have codd block at the database level (only block against other instances of codd, not the app, of course) before applying migrations and release the lock when done. Other instances then will try to apply the same set of migrations but they will all already be applied.

Problems: Q1: If the codd instance that runs migrations fails, the other will try to run starting from the first stopped. Is this a problem? A1: If all migs are in-txn the system should behave just like a single-instance codd with more retries than configured. If at least one migration is no-txn, however, and the first codd runner fails in a no-txn migration, the other instances will retry that migration from the start and repeat work, which could be dangerous. Thoughts 1: Let us not worry about it and not advertise codd as being able to run multiple instances simultaneously, or add a note with a big red warning (we need a note about this even if it says "don't do it" and we don't have one yet).

Q2: If the mig-runner instance fails abruptly (e.g. gets killed or loses the connection to the db and crashes), is the lock released? Thoughts 2: It must be, but I don't know yet what kind of locking we can use that would achieve that. I would hope that these locks are released by postgresql with a broken connection too, but this must be checked.