Drivers discovery mechanism about bblfshd

[dennwc]

Assuming the proposed change in #321 is implemented, we won't need any external scaling for the local use case, only the discovery mentioned in this issue.

Also, I think discovery and "bblfshd as a proxy" can be separate.

For example, we can completely remove bblfshd in K8S and talk to drivers directly (via Ingress/Service) if we figure out a way to use DNS for driver discovery. It may require a custom naming scheme for languages (e.g. pass *-driver.bblfshd.cluster as an address and client must replace * with a language), or maybe adding some metadata to DNS.

For local deployment we may still need bblfshd to return a list of driver addresses (container IPs, or localhost with different ports), but again, we can talk to them directly instead of proxying requests.

This can simplify the case when using a single language: just use a single address for the client, which is an Ingress/Service in K8S or a host:port in local deployment. No separate daemon/proxy needed.

[kuba--]

In my opinion, we can try implement 2 alternative solutions:

• A simple config file or any other static list of addresses
  or (if provided)
• Talk to etcd, where each driver can register.

We can easily make a docker-compose file with all drivers, etcd and bblfshd, or run bblfshd locally but drivers and etcd as docker-compose.

...or maybe even Consul can be a choice.