add projection extractors and use them consistently & add flow_published_at

[jgraettinger]

This is a series of refactors building off of the recent shuffle-service refactor, which introduces a doc::Extractor type that manages the details of querying / extracting / comparing the application of a projection to a document.

doc::Extractor implements handling for default values and, via the last commit, support for extracting date-time values from a document UUID.

The whole runtime is updated to use doc::Extractor consistently:

• when extracting from documents for shuffling
• when comparing over document keys for combining
• when extracting fields from documents while draining combiners.
• when using $parameters within derive-sqlite.

The final commit adds a new flow_published_at projection (alongside flow_document) which extracts an RFC3339 date-time contained within the /_meta/uuid Gazette UUID.

The field name is currently over-rideable by creating an explicit projection of my_field_name: /_meta/uuid/date-time. This could change in the future 🤔 : alternatively, a projection of any uuid having JSON schema keywords format:"date-time", contentEncoding:"uuid" could potentially be made to work, but I didn't take it that far and, for the moment, I think we should consider this an undocumented escape hatch.

Workflow steps:

• All collections will have a new, available flow_published_at projection.
• Collections which don't require their keys will now combine correctly with respect to defined default value annotations.

Documentation links affected:

(list any documentation links that you created, or existing ones that you've identified as needing updates, along with a brief description)

Notes for reviewers:

(anything that might help someone review this PR)

---

This change is 

[jshearer]

I love the Extractor concept, it certainly feels like the right abstraction here. I had a couple of questions, but other than that this LGTM

[jshearer]

Is this unnecessarily overloading the meaning of Result? It feels like this should be an enum instead

enum QueryResult<'s, 'n, N: AsNode> {
  Resolved(&'n N),
  Computed(Cow<'s, serde_json::Value>)
  Default(Cow<'s, serde_json::Value>),
}

[jgraettinger]

It certainly could be a new enum, but using Result to represent a found / not-found result is in keeping with how the standard library uses it. For example https://doc.rust-lang.org/std/primitive.slice.html#method.binary_search

In this sense the Result built-ins are nice because you can do things like result.ok() to discard an alternative value and use it strictly as an Option over "found" status.

[jshearer]

But unlike binary_search, this function always returns "something", specifically something that has an implementation of AsNode.

What would it mean to use query(..)?, for example? Or even query(..).ok()? The whole point is to infallibly extract a value from a document, no matter whether that location is actually present or not. The abstraction of Extractor works so well for exactly this reason: you can hide how a location is extracted, so long as you get some kind of AsNode value out of query().

[jgraettinger]

I'm losing the thread here. query(..) returns an extracted value, which can either be a literal document node (Ok) or an alternative value (Err).

[jshearer]

Is this the same as https://github.com/estuary/flow/pull/1098/files#diff-bf5f2daed95a35cac89611b90ad1e76e41c9ca3ea3ba85e46c8132d749d93912R27? Or rather, why do a binary search here but an .iter().find() up there?

[jgraettinger]

projections are guaranteed to be in lexicographic field order.

[jgraettinger]

https://github.com/estuary/flow/blob/master/go/protocols/flow/flow.proto#L161-L162

[jshearer]

Aren't we searching through a list of projections in both places though? Or is it that the call to projections.sort_by_key(|p| !p.explicit); breaks the guarantee of lexicographic ordering?

[jgraettinger]

We're searching using different predicates. Projections are in field order but not ptr order, so searching for a key pointer has no ordering guarantee.