Determine and implement best way to handle manifest V2 and V3 in schema. Can we avoid duplicating schema files?

Some functions are deprecated.
Some features of some functions are changed.
Some namespaces are changed.
Some decorators (e.g. deprecated) may need differences

The schema parser would need to consider manifest_version in advance.

The idea here is taken from json files in chromium. It's not an attempt to be compatible at a schema level, it just looked like a reasonable approach to dealing with changes.

https://source.chromium.org/chromium/chromium/src/+/master:extensions/common/api/_permission_features.json

min/max_manifest_version keys are available in any schema object, and some schema objects can support an array of objects where differences may be larger.

This illustrates the basics, test in the patch has a bit more to it.

[
      {
        namespace: "MV2",
        max_manifest_version: 2,

        properties: {
          PROP1: { value: 20 },
        },
      },
      {
        namespace: "MV3",
        min_manifest_version: 3,
        properties: {
          PROP1: { value: 20 },
        },
      },
      {
        namespace: "mixed",

        properties: {
          PROP1: [
            { max_manifest_version: 2, value: 20 },
            { min_manifest_version: 3, value: 30 },
          ],
          PROP2: { value: 20 },
        },
]

Comment on attachment 9204332 [details]
Bug 1693403 convert schema format for MV3 content_security_policy

Revision D105846 was moved to bug 1696043. Setting attachment 9204332 [details] to obsolete.

Adding to the "See also" field the pull request for the related changes we'll need to apply on the addons-linter side:

• mozilla/addons-linter#3633 - feat: experimental manifest v3 schema annotations

https://hg.mozilla.org/mozilla-central/rev/a56202a0d743