Overridable OpenAPI Spec

[ashwinath]

This PR allows overriding of OpenAPI spec in the turing charts so that we can change the experiment type enum without maintaining a separate set of openapi specificiations in our private repository. The other motivation is that we are now able to override the servers[].url to allow custom domains other than http://localhost:8080/v1.

However, in this PR, we have generalised it so that we can override any portion of the OpenAPI specification as long as it follows the OAS3 specification.

There is no longer a need to copy over the raw OpenAPI spec files (handwritten) and both the validation and the OpenAPI UI will use the same bundled OpenAPI spec file.

In the Github Actions, we now compile the OpenAPI into one bundle file and put it into the Turing API image instead of building it during the uber Turing API image step as it is required for the E2E tests.

[romanwozniak]

I'm still a bit unclear with this PR as it mixes changes to OAS3 spec files AND SwaggerUI serving configuration. Can we decouple these two steps? I.e, can we do it in this way:

1. When we build a turing-api image, can we also merge files from turing/api/api into a single YAML spec file and include it with the turing-api image (but we don't need Swagger UI at this point)
2. When we build a turing image, we can generate swagger-ui-dist directory and point it to bundled spec file (from step 1)
3. When turing-api server starts, it can merge existing openapi.bundle.yaml in-place with provided patch data

[ashwinath]

I'm still a bit unclear with this PR as it mixes changes to OAS3 spec files AND SwaggerUI serving configuration. Can we decouple these two steps? I.e, can we do it in this way:

1. When we build a `turing-api` image, can we also merge files from `turing/api/api` into a single YAML spec file and include it with the `turing-api` image (but we don't need Swagger UI at this point)

2. When we build a `turing` image, we can generate swagger-ui-dist directory and point it to bundled spec file (from step 1)

3. When turing-api server starts, it can merge existing `openapi.bundle.yaml` in-place with provided patch data

We can but I'm not sure how this solution would help. To me I only see the effects of having a smaller image during the Github Actions but I'm not sure if we gain anything significant. In terms of organisation wise I'm not sure if this does anything better also.

It also adds a lot of noise to this PR.

[ashwinath]

@romanwozniak I have reworked the configuration into a much simpler way. The following changes have been made:

1. openapi.bundle.yaml is commited we guarantee that the developer will have the bundle files. This can be regnerated by just running make in /api/api folder.
2. You can provide an override yaml file. The reason why I chose file over configuration was because there is a bug/harmful feature introduced that lower cased all the keysUnmarshalKey normalizes all map keys to lower case spf13/viper#373), I could not use the fix because i needed to change to spf13/viper instead of ory/viper and i need at least go 1.16 to make it work
3. Configuration is much easier now, it only introduces an additional config that takes in the override file.
4. We serve the new merged in memory YAML, merged or not, and serve it under /static/openapi.bundle.yaml (configurable).

[romanwozniak]

2. I could not use the fix because i needed to change to spf13/viper instead of ory/viper and i need at least go 1.16 to make it work

Now I wonder why do we use ory/viper in the first place (that's a rhetorical question)

[romanwozniak]

Left some styling suggestions, but conceptually it lgtm