Asynchronous management of a push request

[JamieSlome]

Is your feature request related to a problem? Please describe.

When a developer pushes new commits, they are required to subsequently re-push their code once it has received approval from the reviewer, i.e. the commit SHA has been marked as reviewed and approved, and subsequent pushes will result in forwarding the traffic directly to the upstream repository (i.e. GitHub, GitLab, Gitea etc.), instead of blocking it at the proxy layer.

Describe the solution you'd like

Unless a commit or set of commits pushed by the developer fails the "automated" synchronous tests (i.e. server-side push protections), the request should be forwarded to the upstream repository once it has received a review and approval, on behalf of the original developer that submitted the "push request". In simple terms, instead of requiring the developer to re-push, the server manages the initial push by:

1. Send the request to an assessment service queue; i.e. push the payload to the assessment "lambdas",
2. Send the request to a delivery service queue, i.e. forward the entire contents of the initial request to the upstream

In terms of security, we could encrypt the contents of the payload at the first stage (addToAssessmentQueue) and decrypt the payload once we are ready to forward the initial request to the upstream repository, at the Delivery Service.

Developer experience

Ideally, we don't want developers having to do more than a single push for a single commit or set of commits. This strays away from common git practice and is likely to confuse developers.