Patchset reordering and health improvement

It's been some time after we've healed our patchset.

We didn't do anything after the 115 ESR transition and now there has been also the 128 ESR transition, so we should work a little bit on our patchset (at least to improve the state of Android patches).

The previous work was in #40562 (closed), !242 (closed) and other related MRs.

In particular, at the time we decided for this strategy:

• REVERTS : reverting undesirable Firefox patches
• AND-DISABLE : disabling Android Firefox features
• DESK-DISABLE : disabling Desktop Firefox features
• AND-TWEAK : tweaking how Android Firefox works
• DESK-TWEAK : tweaking how Desktop Firefox works
• TOR : torbutton/tor-launcher/orbot integration
• TBB : tor-browser specific functionality, features, UI, etc

The rationale was to make bisecting the patchset easier (and avoid having to bootstrap to verify Firefox changes unrelated to the Tor integration).

This was before Base Browser, but it worked well also after the division. A more updated order (from the current rebase issue template) is:

• Base Browser
  • MOZILLA BACKPORTS - official Firefox patches we have backported to our ESR branch: Android-specific security updates, critical bug fixes, worthwhile features, etc
  • MOZILLA REVERTS - revert commits of official Firefox patches
  • UPLIFT CANDIDATES - patches which stand on their own and should be uplifted to mozilla-central
  • BUILD CONFIGURATION - tools/scripts, gitlab templates, etc
  • BROWSER CONFIGURATION - branding, mozconfigs, preference overrides, etc
  • SECURITY PATCHES - security improvements, hardening, etc
  • PRIVACY PATCHES - fingerprinting, linkability, proxy bypass, etc
  • FEATURES - new functionality: updater, UX, letterboxing, security level, add-on
• Tor Browser
  • BUILD CONFIGURATION - tools/scripts, gitlab templates, etc
  • BROWSER CONFIGURATION - branding, mozconfigs, preference overrides, etc
  • UPDATER PATCHES - updater tweaks, signing keys, etc
  • SECURITY PATCHES - non tor-dependent security improvements, hardening, etc
  • PRIVACY PATCHES - non tor-dependent fingerprinting, linkability, proxy bypass, etc
  • FEAURES - non tor-dependent features
  • TOR INTEGRATION - legacy tor-launcher/torbutton, tor modules, bootstrapping, etc
  • TOR SECURITY PATCHES - tor-specific security improvements
  • TOR PRIVACY PATCHES - tor-specific privacy improvements
  • TOR FEATURES - new tor-specific functionality: manual, onion-location, onion service client auth, etc

I'm not sure we're following it that well, and we could tweak it anyway, if needed.

We don't have an order for MB, maybe we could try to find one.

My experience with the rebase works is that too many commits are going to make the rebases slow (it's more than one minute on my machine for a full rebase).

However, big commits are hard to understand. Also, the bigger the commit, the bigger the chance of conflicts... But to really avoid conflicts, we should make sure commits don't overlap (too much). That applies also when rebasing in minor ESR releases, not only to the big transition.

I think a reason for squashing more used to be that we weren't using FIREFOX_... and -build1 tags, so maybe it was harder to understand the bound of patchsets. But now we are, and that improved everything about rebasing, reviewing rebases, etc...

Also, too big commits are painful to load in GitLab. So, I think we could add bridgemoji on a commit on their own, etc...

Do anyone have suggestions, wishes, etc...?

Other possible work we can do while doing this:

• don't use the bug prefix anymore, but use BB/TBB (or TB)/MB, or whatever we come up with
• get rid of long commit messages: nobody really reads them, and they're likely outdated
• look for uplifts, as usual, the less patches the best
• decide whether to comment or to remove what we don't like (esp. for non C/C++)
• think about testing ideas for each commit

/cc @boklm @brizental @dan @clairehurst @henry @jwilde @ma1 @morgan @pierov