Formalise Rapid Release update process

Overview

Each month as part of our regular maintenance work we should update the next summer's Tor Browser to the next rapid-release version so we can spread out the major ESR transition pain over the entire year. So currently, we would need a tor-brwoser 15.0 branch rebased onto 129, then 130, then 131, etc. (133 is tagged next week).

The work involved is:

• rebase alpha to current rapid-release
• bugzilla audits:
  • spreadsheet generation (see tor-browser-build#41305 (closed) )
  • assigning out each audit to 3 devs
• tag to tag code audits (no issue currently or migrating this script)

Open Questions

Do we want to start making branches like tor-browser-129.0rr-15.0-1 from the relevant Hg tags?

Do we want to also spread out the toolchain update work in tor-browser-build? What would our branching strategy look like?

• option 1: Doing the toolchain update work in its own branch. One more branch may cause a lot of additional mental overhead (main, maint-14.0, and maint-13.5 is already a lot to keep track of when merging stsuff)
• option 2: Add a rapid-release target to tor-browser-build's main branch's configs which use the newest stuff (toolchains, rapid-release branch, etc). This could interfere with normal Alpha development.

ping: @boklm @brizental @clairehurst @dan @henry @jwilde @ma1 @pierov