CXX-3002 update release notes to account for new branch protection rules

[eramongodb]

A new @mongodb/dbx-c-cxx-releases team has been created to selectively grant permissions to bypass new branch protection rules, which are now implemented as rulesets rather than "classic" branch protection rules. This allows for individual rules to be defined and applied to selective branches and tags as a union of protections rules (rather than needing to ensure a single exclusive branch protection rule applies to any given branch). The currently proposed list of rulesets (as well which are currently applied to any given branch) may be viewed here.

Note

All branches and tags are now protected by one or more of these new rulesets.

This new "releases" team is added to the bypass list for all relevant branch and tag protection rules which may conflict with our release process in advance. (Note: individual users cannot be added to the bypass list.) Team members who are assigned the responsibility of performing a release will need to be temporarily added to this team in order to inherit required permissions (i.e. branch and tag creation) for the duration of the release process. This prevents the need to frequently modify the bypass list of individual rulesets: only team membership needs to be updated. The list of members in this team should be kept as small as possible to ensure branch protection rules are regularly enforced (with the exception of the repo administrator, aka the Lead/Staff engineer) (team membership can be maintained via MANA permissions, including having no members at all).

[kevinAlbs]

LGTM with suggestion to link to MANA.

[eramongodb]

Grouping the current set of branches into the following categories:

• Development Branch: master
• New Branches: e.g. releases/v4.1, feature-branch (these do not yet exist)
• Active Release Branches: releases/v4.0, releases/v3.11
• Stale Branches: releases/v3.* (excluding v3.11)
  • Includes the following "legacy" branches: legacy, releases/legacy, and 26compat.
• Miscellaneous: debian/unstable, gh-pages, and releases/stable (requires unique handling).

the new rulesets can be summarized as follows:

• "Block Force Pushes"
  • Applies to releases/stable, but bypassed during a release (via dedicated ruleset).
  • Applies to all other branches and tags, no exceptions.
• "Restrict Deletions"
  • Applies to all branches and tags, no exceptions.
• "Restrict Creations"
  • Applies to all branches and tags, but bypassed during a release.
• "Restrict Updates" (the branch or tag is "locked" from any further changes)
  • Applies to all stale branches and all tags, no exceptions.
  • Applies to releases/stable, no exceptions (should only be updated via force pushes during a release; this may need an exclusion if a force push is also considered an update an exclusion is indeed required).
  • Does not apply to new branches by default (e.g. releases/v4.1 or feature-branch).
  • Note: this is the only "none by default, but include ..." (non-dedicated) ruleset. All other (non-dedicated) rulesets use an "all by default, but exclude ..." target list.
• "Require a Pull Request" (branches only)
  • Never applies to debian/unstable or gh-pages (direct pushes are always permitted).
  • Never applies to releases/stable (should only be updated via force pushes during a release).
  • Applies to master, no exceptions (via dedicated ruleset).
  • Applies to active release branches, but bypassed during a release.

Note

"Require a Pull Request" also applies the following rules:

• "Require linear history"
• "Required approvals" (set to 1)
• "Require review from Code Owners"
• "Allowed merge methods" (Squash or Rebase)