eval: rethink closedness

[myitcv]

Closedness in CUE is an important part of improving the user experience when it comes to detecting errors early:

• It's useful in catching typos; when a user intended to specify field apple but accidentally typed apole, we can detect they specified a field that "do not exist" within some reference schema and tell them at the point of declaration, as opposed to a more distant place where the containing value is ultimately used.
• This more strict "shift left" approach to the shape and type of values can also enable better subsequent evaluation/validation at sites where such values are used.
• In the wider context of a pipelines of configuration, this more explicit approach to constraints is also "better" than an implicit/silent approach as it allows for explicit reliance on conditions/assertions.
• Closedness is similarly useful in detecting when an API contract has been violated. For example, logic can be applied if a client specifies a field that is unknown.
• Closedness also plays some role in the definition of compatibility between API/contract versions.
• ...

CUE has two mechanisms for introducing closedness:

• The close() builtin closes a struct or list argument, but not recursively.
• Referring to a definition recursively closes all structure in the definition's value.

Values that are closed, recursively or otherwise, have that closedness "relaxed" during an embedding, and the resulting structure is then closed.

This issue exists to gather:

• Evidence of problems introduced by the current approach to closedness. This could be anything: from readability concerns, maintainability concerns, impossible scenarios created by closedness in its current form, issues that might/will affect the scalability of CUE... no limit!
• Real-world situations/problem, that could/should/must be fixed by something like closedness (whether under the existing definition, or an entirely new one, or some other means entirely) - i.e. closedness, or something like it, should only exist because it solves a problem
• When considering how to solve real-world situations from the previous point, we should also be clear on other factors that we consider when objectively (as far as is possible) trying to evaluate solutions. For example: readability, simplicity, maintainability, the impact on CUE's ability to scale to very large configurations...

The closedness label is used to mark all related issues for easy discovery: closedness

The list that follows is in no particular order and by no means complete. It is in effect an attempt to distill thoughts from the issues seen over time:

• It is currently not possible to require that a package-level value conforms to a given schema. Embedding the constraining schema relaxes closedness, meaning that typo checking is effectively disabled at exactly the point/time when it is required. Support a must() builtin #575 has been mooted as a potential solution to this.
• The package value that results from an import is currently not closed. cmd/cue: unclear how to validate selector and qualified identifier errors #629 (comment) and related discussions make the point that such an imported value cannot be made more complete/specific/etc by the importer, save for any approach like cue.mod/usr or aspect oriented package-level augmentations in the main module. But even with such augmentations, it's arguably impossible for the importer to do anything further at the point of importing. As such, closing such a package value helps to shift left errors where references to non-existent fields are caught early. The discussion in that thread is picked up in packages: close package values on import? #3772 to continue discussion on that point.
• ...