chore: Support new structure of web features data.json v0.10.0

[jcscottiii]

The Web Features repo changed the structure of the data.json in this PR: web-platform-dx/web-features#1060

Instead of being a map of features, it is now an object with three top level keys:

• features
• groups
• snapshots

This is a breaking change and has caused us to start ingesting features as if they had IDs: features, groups, snapshots

This commit fixes that by updating the defs.schema.json to be the latest version (v0.10.0). This file comes from the web features repo.

After auto-generating the code for that schema file, this commit adjusts the code to use it.

We previously had v0.6.0 of the schema. And since then, some optional fields have become required fields. So you will see the removal of some nil checks (since now the field is not nullable).

This change does NOT ingest the groups or snapshots yet because this change alone is pretty big. Instead, this change keeps the same functionality. Only adjusting for the new data format.

[past]

Can you guard against future schema changes via assertions or similar? It's better to not display any information if the schema has changed than to silently ingest unexpected data.

[jcscottiii]

Can you guard against future schema changes via assertions or similar? It's better to not display any information if the schema has changed than to silently ingest unexpected data.

There are a few things we can do

1. Define our own "Minimally Complete Feature":

   • In this particular instance, we could create a clear, internal definition of the essential fields and their types that constitute a valid feature for our application. This acts as a contract between the data source and our ingestion process.
   • Implement validation checks (assertions, type checks) during parsing/ingestion to ensure that every incoming feature adheres to this contract.
   • If a feature violates this contract (e.g., missing required fields, unexpected types), raise an explicit error to halt processing and prevent the ingestion of incomplete or malformed data.

2. Incorporate Schema Versioning (Preferably Semantic Versioning) - long term:

   • Advocate for adding a schemaVersion field (or similar) to the data.json in the Web Features repo. This version should ideally follow semantic versioning (MAJOR.MINOR.PATCH) to clearly communicate the level of change.
   • On our end, store the expected schemaVersion that our application supports. During ingestion, compare the incoming schemaVersion against our supported version. If the version uses semantic versioning, we can easily ignore patch and minor updates.
   • Previous works: Kubernetes does a similar idea where all resources have a top-level apiVersion key. (but it does not follow semver). More on their apiVersion docs.

I can make an issue and talk about number 2 with @foolip

[foolip]

I'd like to suggest a simpler solution, which is that we release web-features 1.0.0 and from there bump the major version for any breaking changes, which would include any schema changes that aren't pure additions. Would that work?