add create index API as an async job

[pdowler]

this proposed solution is for a parameter-style UWS job that fits the current DAL landscape

[pdowler]

Additional comment about the UWS content included here:

As with TAP-async itself, UWS is a pattern that services implement and I have come to the conclusion that it is not possible to write components that can simply be pulled in and used as-is.

already known: the vosi-tables-ops.yaml is a UWS endpoint and the GET operation can mostly be defined in terms of reusable parts, but the POST operation defines the job-description-language (params in this case) for this endpoint. In the TAP standard there will be an equivalent yaml that defines TAP-async (different params).

But: also note that each operation has an operationId and that has to be unique when an arbitrary set of components are pulled together. Further, you will now see included here vosi-tables-ops-job.yaml which has to differ from a generic uws-job.yaml by having a unique operationId. So, in this case (and in the TAP-async case) one must materialise the uws resources and assign unique operationId values so they are properly nested/connected and do not collide.

The reusable parts of UWS I have identified and included in openapi/uws/

[pdowler]

additional detail on the use of style: form (default), explode: true|false, and type: array|string.

type: array allows for multiple values
explode: true means those multiple values are in multiple param=value pairs
explode=false means those values are in one param with comma-separated values

Here in the "create index job" we can specify something that works like this (sure, doesn't necessarily make sense and might not be allowed):

TABLE=myschema.mytable
INDEX=ra,dec
INDEX_TYPE=long-lat
INDEX_TYPE=unique

but we can specify one comma-separated param and one normal multi param.

That seems fine, but DALI UPLOAD param actually does both:

• you can have multiple UPLOAD params (so type: array, explode: true)
• each value is a comma-separated name,location pair
  So we have prior art for comma-separated values that are definitely not what OpenAPI explode=false is describing. I do need to fix the DALI upload yaml (type, explode) and there I will stick with the regex pattern to specify the content.

So here, I have reverted INDEX to a simpler type: string (single value) and use the description to specify "comma-separated list of column names". I could add a pattern (regex) which constrains values if that's worthwhile, but seems minimal value (for code gen).