Implement arbitrary Queryable interface.

[leehambley]

Status Quo

There are presently two ways to "query" a Depot/Repo.

1. Repo, concerned with the "Repository Pattern" inspired by DDD allows looking up and rehydration of a specific named aggregate. (repo.Rehydrate("users/123") => User<id: 123.....>).
2. Depo, a ES specific storage concern allows subscriptions to simple matchers (globs against partition names (e.g depot.Watch("users/123") or depot.Watch("users/*")).

This PR

A new Matching() API will be added to the Depot as it is more a storage related concern than a DDD concern and I would not expect it to see widespread use in the context of a Command. (this may change, and both Depot and Repo may implement if it is useful in both places)

The Matching() API will run synchronously and will take a Matcher instance. The Matcher will get a chance to explore the entire storage space. Implementations of the Matching() API will be expected to gather Checkpoints with some meta-data about what they matched and why.

The new API is exposed through a new named interface named Queryable, this reflects that maybe Repo and Depot are both queryable, depending on the implementation.

No thought has been given on whether the API should support limiting runtime (other than through respecting the given context.Context or depth in terms of numbers of Checkpoints or distance into the past.

Examples of Matchers may include:

• SessionID("0x00") used to look up any Checkpoints which reference that SessionID in their headers.
• Glob("partition/*") used to look up any Checkpoint referencing an Affix where a partition matching the globbed pattern is named.
• Attribute("partition/*", "$.store.book[?(@.price < 10)]") This would likely be extremely slow in reality but may expose interesting possibilities. The syntax in this contrived example is (likely invalid) JSONPath but some annotation language for pulling values out of the serialized JSON objects would be handy in some instances I think.

Filters

The Matching() API is likely to push Checkpoint hashes onto a stack whilst walking the Merkle tree but I believe the use-cases will prefer consuming events, bounded by affixes in many cases.

I suspect Matching() will return some kind of ResultSet which gives an option of iterating over Checkpoints, or Affixes or Events.

For anti-fraud knowing the metadata about the distribution of Checkpoints where Orders were created over time may be relevant, but one may also legitimately just want to fetch a list of things created in a given session, in which case walking the events without caring about time spans, or the affix boundaries is sufficient.

Combining Matchers

It may turn out to be simple enough to create some boolean combinators for matchers which create new matchers so that one can combine SessionID and Glob() matchers for e.g but this isn't really a concern of changing the Depot/Repo API.