rethink CI integration concept

our CI integration adds two Change states to gerrit, STAGED and INTEGRATING.

the distinctive feature of the current implementation is that staging a change actually puts it into an integration branch, i.e., the management of the integration queue is done directly by the developers.

however, it would be possible to re-interpret STAGED as merely a request for integration, without determining the particulars - the management of the actual integration queue would happen outside of gerrit.

upsides:

• the system becomes a lot more flexible. it can determine batch sizes itself, and it can manage multiple simultaneous queues. it can try different queue compositions to automatically eliminate faulty patches, up to the point that manual re-staging of correct patches would become unnecessary.
  • that queue management could also happen manually by QA personnel
• the number of necessary gerrit-side customizations shrinks substantially, because only the state machine would be affected, without requiring any git repository manipulations.
• already staged Changes can be still approved by more people (without having to rebuild the queue, which we currently don't do)

caveats:

• merge failures would not be reported instantly
  • this is alleviated by newer gerrit versions being able to report mergability against the target branch tip for any open Change. merely conflicts between pending Changes cannot be discovered that way.
• giving the queue management more flexibility means that the system must be able to rely on Change dependencies rather than manual staging order.

the approach presented herein is substantially inspired by openstack's zuul. however, unlike zuul, it doesn't rely on comments and/or review scores to trigger integrations, but keeps the explicit workflow integration. this seems more intuitive, and allows gerrit to reject operations which would implicitly throw off an integration (e.g., pushing a new PatchSet, probably accidentally).