Defer: ftv1 support

[o0Ignition0o]

Followup to #1599 where i disabled sending traces for defered queries, we want to have a look at what needs to be done so we can support it

[prasek]

will this fix the missing trace data in Studio?

[timbotnik]

Ideally we can come up with a solution that is backwards-compatible with the current protobuf protocol, in the sense that for a "good enough" experience we can think of deferred fetches as simply additional nodes in the trace. I'd like to vet that assumption as I've heard mention of things like modifying the protobuf to include finer-grained defer semantics, and it would be great to avoid that if we can in the short-term.

[timbotnik]

As a response to the above thought, a hot take from @glasser:

The query planner produces a query plan which is a tree shape with various node types like Fetch, Parallel, Sequence, Flatten. This is actually a user-visible thing — eg Explorer will show a graph version of the plan. The usage reporting protocol represents supergraph traces with a structure that reflects the query plan precisely (with any field execution traces from subgraphs dangling off of the appropriate Fetch nodes in the tree). The trace viewer happens to squash this into a flat list of Fetch nodes but that's honestly a real shame, and it's great that we have the full tree structure in traces so that once we get around to improving the viewer old traces will immediately show the correct structure.

The defer project added a Defer node to the kinds of nodes that can exist in a query plan (which, again, is a very user-visible thing). I suppose one technically could choose to change "the trace's query plan represents the query plan" into "the trace's query plan represents a mangled version of the query plan that for some reason doesn't have a couple kinds of nodes in it" but I can't imagine why you'd do that. It's just adding a couple lines to the protobuf definition that match the existing query planner definition pretty much precisely.

You're welcome to implement this in a lossy hacky way but if you do so I'll just spend half an hour throwing together the 20 line PR to do it the right way and then you can choose which version to merge :)

To be clear, I'm talking specifically about "should the query plan part of the trace that we store in our storage reflect the query plan or reflect something that's sort of like the query plan but not really". I'm not talking about "should the trace viewer in Studio show the actual query plan or just a flat list of fetch nodes". I think the answer to the second question is probably yes too but that is the next bullet point (and requires a bit of actual design). This bullet point basically just requires mindless copying of a structure that already exists in the query planner into the report format, and updating a couple places that process the various kinds of nodes to know that a new kind exists.

[BrynCooke]

The protobuf should be fully populated now.