feat: add core message payload validation

[jonaslagoni]

Description
This PR enables the following:

1. It conditionally validates the message payload against two core schemas, our AsyncAPI Schema object (default) and the raw JSON Schema draft 7.
2. It defaults to validating the AsyncAPI schema object, if no specific schema format has been selected
3. Indirectly, this enables auto-completion for editors when writing the message payload

Fixes #166
Blocked by #333

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[jonaslagoni]

Because there are no changes to the schema across all v2 versions and v3, I guess it makes sense to validate it against these, right?

[char0n]

I'd say it does make sense. Better to be explicit ;]

[smoya]

I'm concerned about having to maintain this list, add new elements per version, etc.

Can we use a pattern instead of enum here?

{
  "type": "string",
  "pattern": "^application\\/vnd\\.aai\\.asyncapi(\\+json|\\+yaml)?;version=\\d+\\.\\d+\\.\\d+$"
}

Maybe some change is needed. You can test it in https://www.jsonschemavalidator.net/s/VTaBCoGr

[jonaslagoni]

Pretty sure we dont want to enable v1 or future v4 schemas here right? 🤔

[jonaslagoni]

Also would we not want to explicitly state which schema formats are allowed as values? Using something like v2.69.0 would not give a validation error with regex 🤔

Unless you explicitly add a range, but then you are back to having to change this each version anyway.

[smoya]

Good point.

Also thinking about new features being added between versions (no breaking changes). For example, let's say 3.1.0 introduces a new field in the schema so you will have to do a split, serving one schema for >=2.x <=3.0, and another for 3.1.

Porting this to the pattern will be a bit messy. I don't like to maintain all this list but indeed i can't find a better alternative ATM but automating somehow this (we can think about in near future).

[smoya]

I'm suggesting to use a pattern instead of enum here https://github.com/asyncapi/spec-json-schemas/pull/334/files#r1133772134

[smoya]

LGTM!

[jonaslagoni]

/rtm

[asyncapi-bot]

🎉 This PR is included in version 5.0.0-next-major-spec.14 🎉

The release is available on:

• npm package (@next-major-spec dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[asyncapi-bot]

🎉 This PR is included in version 6.0.0-next-major-spec.1 🎉

The release is available on:

• npm package (@next-major-spec dist-tag)
• GitHub release

Your semantic-release bot 📦🚀