Pass through the full request_uri to these proxied services

[PeterJCLaw]

Summary

It turns out that when proxy_pass is given a value with variables in then it always proxies to exactly that value, without any of the normal appending of the rest of the path or query. This means we need to explicitly pass the request uri through in such cases.

Exactly what this means for processing of the content returned from the proxied host is somewhat unclear, however testing of the code-submitter suggests at least that its redirects work as desired.

Code review

Testing

• applied the configuration locally
• manually validated the new behaviour

Links

https://discord.com/channels/1154145712943153252/1154145715518459950/1207444719655849994

Note: given the urgency here and that this is currently broken I've already applied this fix in prod.

[PeterJCLaw]

Merging to reflect that this is deployed (given the urgency & impact on teams of it being broken), however post-merge review would still be welcome.

[RealOrangeOne]

✔️ This change looks ok to me, although it falls squarely in the "How did this ever work" category

[PeterJCLaw]

Prior to #51 we had literals for our proxy_pass arguments. In such cases there are different rules for what's passed to the proxy.
My understanding (though may be in correct) is that given:

location /foo/ {
    proxy_pass http://internal/bar/
}

then a request to http://proxy/foo/something would be transformed into a request for http://internal/bar/something. However with the introduction of variables in #51 we lots that automatic mapping.

One minor gotcha we do now have is that the public-facing root name now must match the underlying one, or we'd need to manually adjust the prefix of the $request_uri to match. That does seem to be something which is possible, though keeping them the same probably simplifies things.