[Discovery] Improve common constraints experience

[robrap]

Issue description and initial comments moved from private ticket: https://2u-internal.atlassian.net/browse/BOM-2721

The process around common_constraints.txt has some issues as we work through upgrades.

1. It is not simple to override a common constraint in constraints.txt, which is where you might expect to do this when working through an upgrade that isn't yet available globally.
2. It is not clear how to mark and clean-up overrides once the common constraints can finally be removed.

See https://github.com/edx/auth-backends/pull/125#discussion_r685288124 for some related discussion.

Additional Notes:

• Some related docs updates:
  • Reminder: If we are making changes to a library based on a new or updated api in a dependency, we need to add and comment a new minimum requirement in base.in.
  • If we know that a library will break with an updated dependency, we should add a maximum constraint in to the library’s base.in, and not just rely on common_constraints.txt.
  • If we release an updated library that fixes and uses a newer version of a dependency that is in common_constraints.txt, we either need to:
    • remove the dependency from common_constraints.txt (if we are ready), or
    • add a maximum constraint to common_constraints.txt for the library update, so no one will try to pick up the new version of the library which will conflict with the active common constraint on the dependency.
      • See example: https://github.com/edx/edx-lint/pull/182

[robrap]

Original comment from @timmc-edx:

Robert and I discussed an alternative to the wget/sed approach today:

1. Specify constraints like django==4.0.8 # common-constraints=override in constraints.txt – this comment will indicate that this package should not be constrained by common-constraints.
2. make compile-requirements fetches a Python script from edx-lint and executes it.
3. The script pulls down a copy of common-constraints.txt and reduces it to only the constraints that don’t have the override annotation.
4. constraints.txt continues to include -c common-constraints.txt but can also have a comment describing how to put an override in place.

Effects:

• A developer looking at or modifying the constraints file would know the current status of any overrides (good locality)
• Only one repo (edx-lint) would need to be modified when we want to change our process, as the script would be downloaded each time

[robrap]

The following is related to common-constraints.txt, but may be an entirely separate question:

In https://github.com/openedx/edx-lint/pull/349#pullrequestreview-1489280178, a common constraint was removed once the openedx org was ready, but the edx org repos were not necessarily ready. The question is whether or not we need a capability for adding org specific common-constraints?