Run separate merge queues for separate branches

[roberthbailey]

In particular, each release branch has it's own e2e test validating the release branch. Merges to the release branch shouldn't be blocked if e2e tests at HEAD are failing, and merges to HEAD shouldn't be blocked if tests against the release branch are failing.

We currently have 2 release branches (release-1.0 and release-1.1) that should have separate merge-bots configured.

/cc @lavalamp @eparis

[brendandburns]

Concretely I think we should have different go-routines in the same binary.

--brendan

[roberthbailey]

Sure, I didn't want to specify an implementation, just the desired behavior.

[ikehz]

This goes along with the work I've been doing to set up critical builds for the release-1.1 branch. I can try to move the needle on this at some point, but, Brendan, feel free to take this if you want.

[ikehz]

We should also just consider only allowing the merge-bot to merge to master. The flow of PRs to a release branch should be slow, (they're all cherrypicks,) and we should be skeptical of all of them.

What do you think @brendandburns?

FYI @quinton-hoole @fgrzadkowski

[roberthbailey]

Yes, please.

[ghost]

SGTM.

[spiffxp]

/cc @kubernetes/sig-testing

[ikehz]

I think this is actually subsumed/changed/fixed by @eparis's work on auto-cherry-picking.