Updated Mutexbot CLI flow to use DB

[Shugenya]

Related to https://databricks.atlassian.net/browse/LKB-3161.

Update Mutexbot CLI flow to use DB for reservation instead of API.

It has 4 CLI methods:
Start - start deployment for given component, region and environment. Returns deployment_id.
Finish - finish deployment (for given deployment_id)
Cancel - cancel deployment (for given deployment_id)
Info - print info about deployment (for given deployment_id)

Start method

• Enter queue:
  Insert deployment record to DB, table deployments
• Loop to check existing reservation
  Check whether any deployments for the same region by other components with a smaller queue position exist that haven't finished yet. Wait and check until there is no queued deployment anymore.
• Start deployment
  Update start_timestamp in the deployments table.

[jcgruenhage]

Good start! I think the areas where this still needs improvement are:

• Better leveraging the type system. This includes using sqlx to provide type checked sql queries, but also to define structs in favor of tuples to ensure we have clarity on what a field is. That the i64 in Vec<(i64, String)> returned by check_blocking_deployments is probably the ID of the deployments returned is relatively obvious, but knowing what the String is, is guesswork without looking at the code of the function. I shouldn't need to read code, names and types of parameters, and types of return values should be enough to know what to expect of a function. If that's not possible, the documentation of the function should cover this. Doing this helps both tooling to verify that the code is working as intended, and helps developers working on the code.
• Right now we're not changing the outside interface at all. Doing that is necessary though, and I think it'd be okay to revamp most of it. New CLI name, new operation modes (start, cancel, finish), new parameter handling. This should be fairly straight forward though.
• To make updating this in the future easier we need to have the tool handle it's DB migrations. Having them embedded in the repo here also means we're able to do code review on them.

[jcgruenhage]

Looks good to me now :)