Failing late when dask-gateway clients passed options are invalid (could been known by a schema)

[consideRatio]

How things work

dask-gateway-server the server and dask-gateway the client can be pre-configured so that the client can send options on how to configure a dask-cluster that the dask-gateway server is to ensure is created.

Problem situation

A typical case is that one configures dask-gateway-server and client to allow sending details on environment variables. In the following failure, environment variables were something that users could specify via options, but if a user specified them without being string valued they errored first at the point in time when workers were created - not when the options were passed.

[...] when specifying environment for the dask workers, if any of the values are not strings, it will fail forever without producing a useful error message to the user. The following error message is shown instead:

HTTP response headers: <CIMultiDictProxy('Audit-Id': 'cfa09cb5-31c2-4d59-ba65-bfe83ffe759a', 'Cache-Control': 'no-cache, private', 'Content-Type': 'application/json', 'X-Kubernetes-Pf-Flowschema-Uid': '67d1c423-088d-42b2-b3b6-8e5f283f4dee', 'X-Kubernetes-Pf-Prioritylevel-Uid': '7cb646fb-2842-4f44-9683-a4989ef19630', 'Date': 'Wed, 08 Feb 2023 20:27:02 GMT', 'Content-Length': '263')>
HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Pod in version \"v1\" cannot be handled as a Pod: json: cannot unmarshal number into Go struct field EnvVar.spec.containers.env.value of type string","reason":"BadRequest","code":400}

Goals to work towards

To fail earlier when dask-gateway client passes config that won't work as can be understood with for example a JSONSchema validation check. Ideally with as little additional complexity introduced as possible in this project as we are very low on maintenance capacity.