Support `required` flag in model definitions

[ankitk-me]

Describe the desired outcome from the user's perspective As a user, I want to be able to mark specific request headers as required for incoming requests to be accepted. This ensures that configured headers are always present before further processing.

Reference config:

http_server:
  type: http
  kind: server
  options:
    requests:
      - path: /api/v1/.*
        headers:
          x-custom-header:
            required: true
            model: string

Acceptance criteria

• Enable user to configure required field in zilla.yaml for model.
• In case of required: true for a header or parameter, and the request omits it, request should result in validation failure.
• The validation logic should be integrated into the model abstraction layer so that required works consistently across bindings.

[jfallows]

Suggest we use existing OpenAPI terminology for required headers, instead of mandatory.

http_server:
  type: http
  kind: server
  options:
    requests:
      - path: /api/v1/.*
        headers:
          x-custom-header:
            required: true
            model: string

@ankitk-me If agreed, then we should rename the issue too. 😉

[jfallows]

@ankitk-me Btw, can the same effect be achieved by using json model with schema that has type: string and required: true without any syntax changes?

[ankitk-me]

@jfallows yes, that's a possible.

{
  "type": "string",
  "minLength": 0
}

[jfallows]

Given that we currently only run the validation on headers that are present, we need to consider backward compatibility when introducing required headers.

This means that if we choose to iterate over the header validations (rather than header values) to drive the validators, then each model will need to be tolerant of null (e.g. missing header value) by default, with the option to enforce required as needed.

Most likely, we would want to add the concept of required to the core model schema, and then determine the best interface to apply the enforcement.

The current validator API expects an actual value to validate, so that may need to be updated to support a null value. Then the validators can take responsibility for all validation failures, including required-value-missing case, rather than placing this burden on each binding that uses the models for validation.