[validation] Check if "@non_exhaustive" is supported correctly

[l-trotta]

Running make validate api=simulate.ingest branch=main returns the following error:

Type '{ "non-existent-processor": {}; }' is not assignable to type 'IngestProcessorContainer'.
  Object literal may only specify known properties, and '"non-existent-processor"' does not exist in type 'IngestProcessorContainer'.

The relevant failing test is actually valid, because ProcessorContainer is tagged with:

/**
 * @variants container
 * @non_exhaustive
 */

so it should allow an unknown value. Does validation consider @non_exhaustive?.

[pquentin]

It at least partially works, as it fixed one error here: #4373

[pquentin]

non_exhaustive is documented to only apply to enums, but ProcessorContainer is a class, which is why it does not apply here.

Looks like @swallez wanted to implement it here:

elasticsearch-specification/compiler-rs/clients_schema_to_openapi/src/schemas.rs

Lines 281 to 282 in 291ffd3

	// TODO: interface definition container.non_exhaustive
	let _non_exhaustive = container.non_exhaustive;

But I don't know how to express that in TypeScript. (For enums, it's simple, we just add | string.)

[pquentin]

We discussed about this offline:

• My link above is about OpenAPI generation, not validation. @swallez is currently working on that area and plans to fix that TODO as a drive-by change, by allowing additionalProperties for non exhaustive containers.
• There's a tension in the validation between respecting the specification exactly (by not erroring in the above case) and being aware of new enum variants or container keys. We discussed adding a strict mode, but it would have to be run manually, making it essentially useless. The best option is to actually ignore exhaustiveness in the validation (even for enums), and ignore YAML tests that are using unknown values on purpose. That way we still get failures for new values and hopefully do remember to add the non exhaustive tag.