Make service to port number mapping more explicit

[rylev]

Services currently expose their ports through different means. The Python service, for example, writes the logical port it exposes to stdout and the Python service code knows to look there for the port. Docker services do this by exposing a port from their Docker file.

This usually is opque to users of the test-environment crate because they simply ask a test environment to replace a logical port with the actual port the service is listening on in the host.

However, some environments don't use services (e.g., spin-test), and they are instead supposed to know the magical mapping between logical port number and what service is available there (e.g., port 7 is TCP echo and port 80 is HTTP echo). With more services this will become even more confusing.

Instead, we should not be writing port numbers into Spin.toml templates but instead referring to the services directly:

# Instead of:
# allowed_outbound_hosts = ["*://127.0.0.1:%{port=7}"]
# We now have:
allowed_outbound_hosts = ["*://127.0.0.1:%{port=tcp-echo}"]

The environment can then ask a specific service for its exposes port. And if a test runner doesn't use services, it can decide how best to handle port mapping from service to port.

What about services that expose multiple ports

We currently don't have any services that expose more than one port, but that might change in the future. Perhaps in the future we extend the syntax to something like:

allowed_outbound_hosts = ["*://127.0.0.1:%{port=my-new-service[some-feature]}"]

[rylev]

Some more thoughts:

• The service needs some way to declare a certain port is its "default" port (i.e., the port that will be selected when someone writes ["*://127.0.0.1:%{port=my-service}"] - in other words this is just sugar for ["*://127.0.0.1:%{port=my-service[default]}"] ). All other ports would have to be referred to by their name directly (e.g., ["*://127.0.0.1:%{port=my-service[my-port]}"]).
• For Python services we could imagine the Python service directly specifying a port as the "default" port since Python services already specify some logical identifier (currently itself a port number) to the port actually exposed by the service. We could just change this mapping to be name <=> port instead of port <=> port.
• Docker is more complex since we inspect the ports the container exposes to know what the host port number that exposes the guest port. Docker services would need some additional configuration file to specify the names of ports (including the "default" port). One could imagine a config file that would specify that the container is expected to have some port N exposed to the host and that N is called some name (e.g., default = 80 would say that the guest port 80 in the container is known as "default").