Support mqtt streetlights AsyncAPI validating proxy

[jfallows]

Describe the desired outcome from the user's perspective
As devops, I want to deploy a validating AsyncAPI proxy for MQTT Streetlights example.

Acceptance criteria

• All validation defined in MQTT Streetlights AsyncAPI spec is enforced by Zilla

Additional context
Message traits refer to common headers, which map to mqtt user properties, so we need to support validation of PUBLISH user properties.
Operation Traits mention qos but the expectation of behavior for PUBLISH via other qos values is not defined clearly.
Security Schemes mentions apiKey with placement of token in user field (not password field) during CONNECT but we do not currently have a guard to validate api keys.
Security Schemes in general can support http bearer, which would then align with out support for jwt guard.