Update Git proxy's governance to latest FINOS standard and formalize agreement reviews

[kriswest]

Git proxy's governance docs are:

• slightly behind the current FINOS standard (https://github.com/finos/software-project-blueprint/blob/main/CONTRIBUTING.md)
• exist within the website, rather than git repo: https://git-proxy.finos.org/docs/development/contributing
  • Repo version of teh doc is not necessarily in sync, but does refer to the website for governance details: https://github.com/finos/git-proxy/blob/main/CONTRIBUTING.md
• In need of an update to guide on what changes to Git Proxy should be review by a maintainer from a different firm to the one raising the PR (to ensure good governance, while limiting slow downs caused by reviews).

The original discussion ca be found here;; #1646 (comment)

[kriswest]

As Git Proxy is key piece of infrastructure used at multiple firms to enable contribution and, essentially, a security control, we need to be careful with its governance and ensure that it continues to meet the needs of all firms involved. Hence, I propose formalising the gentleman's agreement that we've had that firms don't review and merge their own PRs, where those PRs would:

• Force a major release (breaking changes)
• Introduce a new feature or other significant architectural change
• Change the projects governance in any meaningful way.

With that in place it would still be possible for the project to head in a direction that does not suit one of the participating firms, hence, we should allow for decisions to be appealed and potentially revered - although this will often be done with a new PR. In the event that a change appears contentious we should seek consensus amongst the maintainers.

I think we should also allow for pre-approval, where a meeting or previous review by other maintainers pre-approves a change that is not yet complete, allowing it tits review to be finalized by another maintainer from the same firm.

We should also permanently exempt changes that relate to project infrastructure maintenance, dependency maintenance, bug fixes and test coverage unless the change meets one of the conditions defined above (e.g. a dependency change that forces architectural changes).

I think this level of governance is necessary for Git Proxy, Particularly given that it used to contain some significant errors that precluded its use as an effective control at our firm. I think it is in a much better place now, but needs to be maintained at a high-level, by corss-team reviews, ensuring that future changes do not introduce flaws that can be exploited by a bad actor (or overly creative AI)