feat: schema validation

[nathanielc]

With this change models and model instance documents are validated. The validation rules are in large part the same as in composedb with a few differences:

• Models can now be updated (more below on this)
• Relations are only partially validated, we ensure the field is a valid stream id of the correct type and nothing more. Applications building on Ceramic can extend this validation to load the stream.

Models streams now allow data events that update the model. These are the rules of updating a model:

• Only the name, description, implements and schema fields of a model may be modified. All other fields are immutable.
• The schema must not make a breaking change
• An interface may not be updated

A model instance document stream now supports a new header value modelVersion that defines which version of a model to use when validating the document. The modelVersion must be set to the CID (not stream id) of event within the model stream corresponding to the version of the model used to validate the instance. If not set the modelVersion is defined to be the CID of the init event of the model, aka the CID part of the model stream id. Note the model version is mutable so a stream that initially validated against one version of a model may change to validate against a newer version of the model. This change is explicit and required.

The result of these rules is that models can publish new backwards compatible versions. Model instances can explicitly update to those new versions by both updating their document and updating the model version header thus ensuring that the new document structure is correctly validated. Existing applications that take no action will see both old and new model instance documents however as the schema changes are backwards compatible the application will have no ill effects. Applications that update to handle the new schema can do so while handling cases where many model instances will still use the old schema.

Additionally the mechanism that requires the controller of a model instance to update to a new version of a model means that a model publisher cannot invalidate existing model instances by making changes to the model.

[nathanielc]

This change is large, to help with review there are two halves to the changes:

1. The half that given a model or a model instance can validate it
2. The half that given a datafusion record batch of events calls the validation code from the first half

See the pipeline/src/aggregator/validation for the first half and the src/pipeline/aggregator/mod.rs for the second half.

[nathanielc]

This method is the heart of all the changes. Basically the aggregator flow now includes four explicit steps.

1. Join events with previous
2. Apply patch/updates based on stream type specific rules
3. Validate newly updated events
4. Store events with their validation status

[nathanielc]

This file has a few TODOs. This logic is currently unused. Validating that models implement interfaces will be a follow up change as this one is large enough. This scaffold code simply shows where it will fit it.

[smrz2001]