Implement the Service API

[shaneutt]

Blixt started with intentions to implement just Gateway API but it kinda toes the line of being a Service implementation. In fact, the prototype for Blixt abused Service (MetalLB, specifically) for faux IPAM as a hack to get things working.

The purpose of this issue is to discuss and consider whether we would implement the Service API using Blixt, but ideally we do this with as limited scope as possible. I am particularly interested to see if we can build off of KEP 4770 so that we can be an alternative, while deployed compatibly alongside existing default cluster implementations.

[shaneutt]

I was talking with MetalLB maintainers and they mentioned we could (even if as an interim solution) use the MetalLB controller to assign the IPs to the Service but not have to do the "hijacking" that we do currently. This can be done by simply disabling the speaker component:

https://github.com/metallb/metallb/blob/main/charts/metallb/values.yaml#L259

And then when the controller assigns the IPs we can just take over from there without clobbering speaker configuration. Later, we can decide if we want to implement IPAM ourselves but this gives us a smaller chunk to bite off at first.

[shaneutt]

We discussed this one in our community sync today (join #blixt on Kubernetes Slack if you'd like to join those, we do them ad-hoc and vote on times). We've decided that we do want to take this one on:

/triage accepted
/priority important-longterm

For this first iteration, we only need bother with a basic level of support and we can start by using MetalLB as a dependency (as mentioned above). We could make Gateway+TCPRoute/UDPRoute controllers simply convert to our Service implementation under the hood as a part of this work to reduce redundancies in implementation.

Note: We consider this blocked by https://github.com/kubernetes-sigs/blixt/milestone/8 and not yet ready for work.