Implements two flavor of library support for service-discovery:
- GetConnectionString (arbitrary strings) augmenting existing
functionality already in asp.net core
- GetServiceUri (uris) can be combined
from a protocol/host/port triple
See the **extensive** doc `service_discovery.md` that is filled out in this PR. That documents pretty much everything about how this works now.
* Add test for container -> host communication.
* Small tweaks
- Modify frontend-backend app to print backend url
- Fix log in docker runner
- Rename test to use docker instead of container
* More clean up
- Don't set container port if the service isn't a container
* Bind to all interfaces on linux only
- Turns out the same alias works fine and docker will
associate multiple IPs with a single alias
- Remove the docker run command from the output and leave it in the log
- Dump out the backend host names in the frontend backend example
This tries to add some auto-detect magic to make common scenarios work
without any extra configuration, which avoiding doing obtuse stuff.
- We ignore the ports in launch settings (avoid conflict in the
hello world multi-project case)
- When we infer bindings based on launch settings we set them to
auto-select a port
- The user setting a port via tye.yaml will always win
- Bindings that are not inferred from launch settings still work
the same way (we don't auto-auto-select a port)
- When we deploy we ignore https
The HTTPS behavior might need discussion, but we haven't started looking
at a recipe for HTTPs inside the cluster in k8s, and it's not clear
whether we even want to.
One could also make the argument that we should skip TLS locally because
we're not doing it inside the cluster. Someone writing an app today that
assumes TLS in their code (using https URLs, or gRPC + TLS) will have
a non-trivial path to k8s for now anyway. So, skipping https bindings
for k8s really just makes us more honest.