Version APIs within code, not config

[GageGaskins]

Description

Move the versioning of endpoints to their respective handlers, not the config.

Gateway

• Move all versioned endpoints under new /api prefix. Attach auth middleware to this prefix so any registered routes still get proper auth
• All nonversioned endpoints still register to root / endpoint, ie swagger, health, metrics

Why

We're not doing versioning properly for a multitude of reasons.

• Having the version be part of the configuration doesn't accurately represent what version endpoints the Gateway supports. With the current process, I could create a v17 of the gateway that is still on v1 code internally, or vice versa!
• Having the api version as a part of the Gateway deploys breaks client code very easily as the entire API path changes. There is no backwards compatibility outside of making routing level changes.
• Putting the versioning in the handlers, we allow per endpoint rollouts/backward compatible fixes etc vs having to have whole version upgrades for the Gateway.
• These semantics will also make the future livy api clear with the endpoints registering as /api/livy/<endpoint>