openapi: Extend the /v1/compile API

[philipaconrad]

What changed?

This PR tracks a planned extension to the Enterprise OPA /v1/compile API, as part of our intended support for UCAST and data filtering experiments.

Currently, my approach is to add a single additional string option under "options" ➡️ "targetFormat". Allowed values for the field include: json_ast (the default), sql, and ucast.

Here's what an example /v1/compile input might look like:

POST /v1/compile HTTP/1.1
Content-Type: application/json

{
  "query": "data.example.allow == true",
  "input": {
    "subject": {
      "clearance_level": 4
    }
  },
  "options": {
    "disableInlining": [],
    "targetFormat": "sql"
  },
  "unknowns": [
    "data.reports"
  ]
}

The response would then resemble:

{
  "result": {
    "queries": [
      [
        {
          "index": 0,
          "sql": "WHERE ...\n-- not actually sure what this SQL query would look like for the reference query."
        }
      ]
    ]
  }
}

[srenatus]

I believe we may need further per-targetFormat options?

For example "ucast" would have different valid inputs (PE fragment) depending on whether it's meant for conversion with ucast.as_sql, or ucast-linq or ucast-prisma. Could be a "flavour", akin to database dialects? 🤔

Same for SQL, if we want to expand the set of builtins that we can translate, this could depend on the target dialect, too.

[philipaconrad]

Right, that's a good point. 🤔 I suppose we could switch this to be an object type or something that allows us to nest target-specific options.

[chendrix]

I was interested in seeing if we could actually separate out the response types for different targets into different application/json+<target> MIME types.

I don't want to overload the response to just generic arbitrary JSON