API versioning

[mbroecheler]

Currently, a datasqrl compiled data pipeline supports only a single API definition. To evolve the API, one would have to compile a new pipeline. However, when the changes only impact the API layer (and not the streaming or database layers) that would be overkill since all we need is to update the API layer which can then connect to existing databases.

To support this, I propose the following:

• we add an api key under script which is a map that maps version keys to { schema : STRING, operations: [STRING] } objects which are treated like the graphql schema + operations pair at the top level. We keep the graphql and operations keys at the top level and map them to version key v1 by default.
• we update ModelContainer to extend LinkedHashMap<String, RootGraphqlModel> so it's a map of version key to the model definition.
• we then process all schemas in a for loop and combine the extracted SqrlFunction definitions.
• on the server side, we instantiate the verticles under the respective api keys.

For example:

{
  "script" : {
     "main": "main.sqrl",
     "api": {
        "v1" : { "schema": "api-v1.graphqls" },
        "v2" : { "schema": "api-v2.graphqls" }
     }
  }
}

Would result in ModelContainer being a map with v1 and v2 keys that point to the respective model definitions.

On the server, we would then have the following endpoints:
/v1/graphql, /v2/graphql, /v1/rest , /v2/rest, /v1/mcp, /v2/mcp (depending on what APIs are enabled)

[mbroecheler]

Would we have /v1/graphiql and /v2/graphiql or is it possible to share one graphiql instance with configurable endpoint based on versions?

[mbroecheler]

For 0.8 we only want to implement the changes to the ModelContainer and update the endpoints to use the version (v1 by default) since that change is breaking. The rest we can add incrementally later without breaking changes.