Formal process and infrastructure for release branch development

[mhofman]

What is the Problem Being Solved?

We currently cut releases from the release-* branches (in particular release-mainnet1B at the moment, previously release-pismo). So far we've only had to branch and cherry-pick commits from the master branch, however with the release and master branches diverging, we're finding ourselves in need to have direct PRs against the release-* branches.

Furthermore, we're getting to a point where multiple releases may be worked on concurrently and independently, and since these releases remain sequential, we don't want to interleave their PRs on a single release branch.

Description of the Design

Ability to create a "dev release" branch, which has as much as the normal CI operational on it, including required checks.
Maybe leverage glob matching where possible.

We may not want to enable auto-publish for these branches to avoid a proliferation of tags

Security Considerations

None

Scaling Considerations

It might be ok to have the branch creation require a manual admin step, but it should require as little customization as possible.

Test Plan

Manual most likely

Upgrade Considerations

Not in itself, but in support of upgrade work

[aj-agoric]

closing as much of the work is completed or transferred. @mhofman will create the new issue for remaining scope

[mhofman]

Created #9920