supervisor: accept Orchestrator interface instead of concrete type

[matheuscscp]

Hi 👋

This project is pretty cool! Thank you very much for it 🙏

I'm filing this PR to make the Go code here a bit more extensible. If we accept the connection.Orchestrator interface instead of the *orchestration.Orchestrator concrete type in the places I have changed in this PR I would be able to reuse some of this code in another project that imports this one. Please let me know if this is okay 🙏

[jcsf]

Hi,
Can you expand a bit more on what you are trying to achieve. Supervisor and orchestrator are 2 internal structures of cloudflared, we need to better understand the use case in order to allow a change on one of this structures.

[matheuscscp]

Sure! Thanks for paying attention to this PR 😁

I have created (yet another, for what it seems) Gateway API controller for Cloudflare tunnels:

https://github.com/matheuscscp/cloudflare-gateway-controller

I'm really happy with the results so far. I'm mapping a Gateway object to a tunnel. The controller creates a Deployment with a cloudflared container inside, and a sidecar I wrote as part of the project. I have a single ingress rule that sends all the traffic to http://localhost:8080, where the sidecar is listening on. It proxies to the right Kubernetes backend, and allows me to implement several requirements of the Gateway API.

For what's relevant to this PR, I want to merge the sidecar and cloudflared containers into one, by directly importing the Go packages of github.com/cloudflare/cloudflared. This allows me to implement a number of other things as well.

I have a working proof of concept here, that depends on the changes in this PR:

https://github.com/matheuscscp/cloudflare-gateway-controller/blob/a477c3d7f432d4d76bf84602a5479742ffb39f0c/cmd/cfgwctl/cloudflared.go