Blueprint: Move hook invocations into a client-side gRPC service

Gitaly provides two different mechanisms that allows clients to hook into writes that a subset of our RPCs in the Operation service perform:

• Gitaly executes certain Rails-specific endpoints like /internal/pre-receive, /internal/allowed and /internal/post-receive. These endpoints execute logic like counting in-flight changes, but also verify whether a certain change is allowed by a specific user.
• Gitaly handles custom hooks that can be installed as binaries into a repository.

Both of these approaches have significant downsides:

• We have Rails-specific logic in Gitaly that are not applicable to usecases where Gitaly is used as a standalone product.
• The interface between Rails and Gitaly is only loosely defined by Rails. This has caused multiple incidents in the past when the interface has accidentally changed.
• Custom hooks have direct access to the repository. This makes it hard for us to iterate on the repository format given that these hooks may access data structures directly.

In Discussion: Use gRPC backchannel to invoke acce... (#5135 - closed), we have thus discussed an alternative approach to handle this via a client-side gRPC server. Gitaly will start to provide a gRPC service definition that clients can implement. If configured, Gitaly will then connect to and invoke this gRPC service to invoke RPCs that have been implemented by the client. This would allow us to get rid of both the Rails-specific logic as well as custom hooks in favor of a clearly-defined interface.

We should create a blueprint for this idea that provides details around how this new mechanism would work. Most importantly, this blueprint should also document how the old concepts would be mapped to the new gRPC service. The blueprint should serve as the basis to gain consesus across groupgitaly and groupsource code as well as ~"group::authentication and authorization".