Runner registration

[scott-taubman]

We need to develop a workflow for registering runners both for the shared / public runner pool, as well as private runners for specific teams.

Possible steps / things to consider (future sub-tasks):

• There should be a registration token that functionary application administrators have access to that would be used for public runner registration.
• Each team would also have a registration token that the team admins have access to.
• The runner container would allow you to launch it in registration mode, where you supply the token and other relevant config information. The runner would then register itself with the functionary instance and get back the information it needs to operate (location of and credentials for dependent services).
• When registering a runner, the backend likely needs to provision an account on the message broker that has access only to consume from the queues that its tasking will go to publish only to the exchange for tasking results.
• Some amount of queue declaration and binding will presumably be needed as well.

[scott-taubman]

This is fundamentally similar to the registration process for something like a GitLab runner, so that's probably a good reference point for what a reasonable workflow looks like from the user perspective.

Also, we should document and test the exchange / queue / topic design before we start work on this to make sure our ideas about how the routing is going to work pan out.

[scott-taubman]

As I think through this some more, I think the routing should be kept simple initially, with runners consuming from only one of two queues: the public queue or a shared queue for the team or environment's pool of runners (side-note, might have to think about supporting that distinction a little bit). I don't believe RabbitMQ (or any alternative we might explore) would be able handle the routing needs for something like the arbitrary runner tags that GitLab supports. There would have to be some application level routing logic to support that, which isn't the right thing to invest in at this stage.