transformers, persisters, verifiers

[matt-beanland]

Currently the instance/party (and place if done yet) extension DSL is just purely introspected.

We should use transformers, persisters and validators according to https://github.com/ash-project/spark/blob/main/documentation/how_to/writing-extensions.md

The transformers can inject useful methods onto the extended resource.
The persisters can make introspection data we find useful, perhaps to other enhanced resource's transformed methods.
The verifiers should raise at extended resource compile time to provide useful guidance.

Extended resources are unknown to each other at their respective compile times.

Refactor so action helpers are not needed. Most test cases should be unchanged, but not a pure refactoring as we'll include negative tests of the verifiers.

[matt-beanland]

Created verifiers for the DSL. These raise at compile time of the extended resource.
Created transformers which process the DSL and inject methods similar to that done by the action helper. We should inject these into the create/update actions, so that there is no action code to write in the extension unless there is something unusual to handle, in which case the local helpers can be called. This enables the ActionHelper to be entirely removed.

We also need to do doc, review DSL spark documentation and livebook.

When we release we will up the version to 0.3.0 was we have broken compatibility not with the DSL (we've extended it), but with the developer contract as their actions were coupled to ActionHelper which is removed, and their actions may be unnecessary (after domain API rewiring) or need to be rewritten to use helpers now on their resource. So the get actions for free, or helpers which are intrinsic to their extended resource - a win.

[matt-beanland]

We've restructured the DSL so we have behaviour and actions, and added introspection functions on both Diffo.Provider.Instance.Info and the extended instance, including convenience functions. We have verifiers to ensure that characteristic names, feature names are unique, and feature characteristics names are unique within the feature. For parties, we also ensure that party/parties roles are unique. This is very cool as we have a unique key for the party schema which allows multiplicity of parties in a given role, and also allows a given party to have multiple roles to the same instance (there will be multiple PartyRef connecting them). This is so far ahead of previous implementation it is not funny. Also starting to see value in {array: structure} for relationships rather than {map: structure} since so flexible.

[matt-beanland]

Completed. The extension now uses persisters to bake specification, characteristics, features, and parties onto the resource at compile time. TransformBehaviour generates build_before/1, build_after/2, and single-item lookup functions (characteristic/1, feature/1, feature_characteristic/2, party/1) and injects :specified_by, :features, :characteristics arguments onto declared create actions. The DSL is restructured into structure do (what the instance kind is) and behaviour do (what it does), eliminating all manual ActionHelper wiring from domain resources. Verifiers cover uniqueness and validity for all structural sections, cross-reference checks (party_type must extend BaseParty via PartyInfo.party?/1), and behaviour action existence. Instance.Extension.Info and Instance.Info expose matching runtime lookup functions. The livebook has been updated to the new DSL. 521 tests, 0 failures.

Note that behaviour is just commenced and is still a bit inflexible as we may not want all possible characteristics to be present on create, etc.