Based on conversations in T322152, it has been decided to implement a gateway for REST routing. To remove ambiguity and to standardise, from now on I will be calling this the "REST gateway".
Notes on reasoning etc:
* A dedicated gateway for a separation of concerns - API gateway has thousands of lines of generalised config, REST gateway will have ~hundreds specific to restbase work.
* The API gateway is in theory _only_ for api.wikimedia.org. The REST gateway is for requests coming for /rest_v1/ on multiple domains.
* Global settings - HTTP headers can be set for all requests so as to ensure RESTbase compatibility, this would involve conditionals etc within the API gatway
* Separation of concerns - ideally the API gateway will be a self service platform for teams configuring new services themselves, the REST gateway will not be and will only be managed by people with direct needs and experience with RESTbase and the REST gateway
* A component to be deprecated - we are building the gateway with an eye to ultimately removing it once it is no longer needed. This is of course a risky assumption as these kinds of things stick around historically, but we do not plan on the REST gateway being a component we keep in place.
* Custom rate limiting configuration - we can create a new, independent system of rate limiting within the REST gateway as opposed to living alongside or customising the existing API gateway rest config.
The REST gateway's main function is to map requests that would usually be aimed at restbase to requests that services expect. This will mostly be via simple URL reformatting, header setting and other forms of polish.
Ideally we can reuse the existing chart for the api-gateway with a custom configuration set for the REST gateway. This configuration should be in an independent file within the chart so as to avoid any cross-impact from changes to the traditional API gateway. Envoy limitations unfortunately oblige us to `include` this template rather than make it a real individual file so we'll need a clear toggle for this, and probably also to move the existing API gateway configuration to a dedicate file for `include` purposes also.
[*] Move API gateway configuration to include
[*] Create REST configuration file and configuration toggles
[ ] Implement URL mangling configurations from ATS, Varnish and within RESTbase in Gateway config (needs a dedicated ticket)
[*] Add RESTbase security headers (T326321)
[ ] Handle edge cache invalidation (T324200)
[*] Create Helm definition for REST gateway
[ ] Create LVS service
Open questions:
* Ratelimiting configuration and criteria - probably needs its own ticket