multiple staging support

[xmo-odoo]

Currently the mergebot assumes each branch only has one staging going on, and this assumption is leveraged in several places (usually by checking a branch's active_staging_id for information).

This is likely non-trivial, but would be a requirement for advanced staging modes e.g.

• incremental staging (#951)
• optimistic concurrent staging (create staging 2 on top of staging 1 if there are enough PRs waiting)
• concurrent split staging (#497) as well as pessimistic concurrent staging (the same without a split, assumes the current staging is going to fail)
• pessimistic splitting (stages a staging and its splits at the same time such that one of the splits can be merged if the main staging fails)
• ...

Changing this would likely require some sort of intermediate staging strategy object, which can bundle a bunch of stagings and provides relevant query operations. Note that this also impacts batches and PRs as we dereference their stagings e.g. to cancel the current staging if they're part of that on r- or w/e.

Shower thoughts:

• strategy needs to be on the project, with links to branches I guess? Stagings (the representation) should probably stop doing staging jobs and delegate to strategy records in order to handle variable geometries e.g. concurrent stagings, queue, ...
• strategy probably needs to provide some templates in order to render stagings on the home page and in the branch list

[xmo-odoo]

moc note: technically merge queues / trains and batches are not incompatible, you kinda just queue batches. So you could have queues of batches n > 1.

[xmo-odoo]

xdo note: would strongly benefit from the direct staging com' between mergebot and runbot: if the mergebot has to push branche, for concurrent stagings it needs multiple branches, but then if it cancels the entire thing the branches will keep running on the runbot. So would make more sense for the mergebot to send build requests to the runbot when it creates / cancels / fails a staging.