How should redirects interact with `allowed_http_hosts`?

At the moment, Spin's outbound HTTP interface automatically follows redirects. This happens within the reqwest stack in the Spin host, and therefore bypasses allowed_http_hosts.

Generally, this is reasonable, because it means a component granted access to, say, twitter.com does not need to be reconfigured when that domain starts redirecting to x.com. However, there may be cases where it is not safe to follow the redirection: consider the case where the operator of a Spin hosting environment (e.g. a Kubernetes cluster) wants to prevent redirection to internal services.

To complicate matters, our understanding of wasi-http is that the host should not automatically follow redirects; it would be up to a higher-level HTTP stack running inside the guest to manage redirect policy. In that case, the host cannot know that the request to the non-allowed x.com is merely following a redirect from the allowed twitter.com - it must enforce allowed_http_hosts on all requests. Which could be vexing for an application which just wants to get the latest cat GIFs and not have to constantly chase the hostname du jour.

(As a side note, Cloud does not currently automatically follow redirects. So it avoids the 'policy bypass' problem but runs into the 'chase the hostname' problem.)

Start with the reqwest stack in the Spin host and the wasi-http redirect expectations described in the issue. Compare this with Cloud's current behavior and trace how allowed_http_hosts is enforced. Done requires a documented and implemented decision for redirect handling that preserves the intended host policy.