New pull request assignment proposal

This patchset is the implementation of a new workflow for assigning pull requests to the Rust project contributors.

2023-11-08 UPDATE: After a meeting with T-infra, it was remarked that this block of changes are hard to review, so we agreed a plan to split into smaller bites. This PR will stay as tracking issues for the work being split into smaller pull requests:

[ ] Step 1: Change pull request assignment algo (#1745 ):
- create new DB table, just store there "how busy ppl are"
- add new mechanism to assign pull requests
- add CLI tool to populate the new DB table and synchronize it. Make it so that it will speak HTTP instead of using public triagebot APIs.
[ ] Step 2: Implement the backoffice where people can set themselves on time-off.
- TBD: standalone app or inside the Triagebot codebase?

A slightly old design document is at this HackMD link.

This proposal was discussed separately in a number of meetings with the compiler team (also mentioned to @Mark-Simulacrum).

Summary

The current pull request assignment is basically randomly assigned among team members. The new proposed workflow has the following features:

each Rust project contributor belonging to a team (I'd start will a small cohort of testers) can set their own review capacity and time off using a web backoffice
the web backoffice will persiste these data in a DB
everytime a pull request assignment is invoked with r? <team> or <team_member> the triagebot will check the current availability and workload of the candidates and assign the pull request to the team member less busy, excluding automatically those that are on time off in that moment.

Permissions and Authorization

This backoffice is a simple form listing all team members. It is served by the triagebot (from triagebot.infra.rust-lang.org/). Access to this backoffice is gated by a GitHub App. Users allowed to this backoffice: 1) must be logged into GitHub 2) must agree to the share some details with a GitHub App (only to read their profile) 3) must be a Rust project team member 4) the team they belong must be whitelisted in the env var NEW_PR_ASSIGNMENT_TEAMS (see documentation)

Team leaders are considered administrators and can see the preferences of every team member. Normal team members can only see their own preferences and those of team members that agree to share theirs within the team.

DEPLOYMENT

There are a few env vars to enable the new PR assignment and retrict access to this backoffice (see: .env.sample).

My idea would be to iterate on this pull request and iron out all the wrinkles visible without deployment:

Deploy this changes but keep the new PR assignment DISABLED. The web backoffice will still be accessible.
Team members can access that, start playing with with it fill their preferences
When we are all confident about these changes, we can flip the env variable USE_NEW_PR_ASSIGNMENT and have the team listed in NEW_PR_ASSIGNMENT_TEAMS use it for real.
After a first period of tests, add more teams

Of course, happy to receive inputs!

TODO

I also left a few notes about a few items to be implemented, in my opinion also in a second interation; see the documentation.

(I will iterate on the pull request description to add context)

rust-lang / triagebot