Protobuf field extraction function

[purplefox]

We will create a SQL function to extract field information from Protobufs, similar to

https://docs.ksqldb.io/en/latest/developer-guide/ksqldb-reference/scalar-functions/#extractjsonfield

We can consider allowing a simple SQL query (without joins or aggregations) to be specified in source configuration to allow the fields to be extracted at the source level without having to create a materialized view to do this.

[alecthomas]

Protobufs are not self describing, unlike JSON and Avro, so there will need to be some way to associate a stream with a particular protobuf. Prana will need to either accept the transitive closure of imports in order to compile it itself, or accept a pre-compiled FileDescriptorSet. The latter is probably preferable for simplicity.

[mightyguava]

TODO

• [x] Protobuf selector #142
• [x] Parse protobufs, loading descriptors from disk #144
• [x] gRPC API for registering descriptors #153
• [ ] Registering new protobufs should reload schema for relevant MessageParsers #165
• [ ] maybe? generalize protobuf selector library for all data types and fully replace gval #166
• [ ] maybe? support the Any type. (We have no internal usages since we are tied down by Wire only supporting proto2) #167

[mightyguava]

The protoreflect.Registry we are using right now is insufficient since it only allows registering new protos, not updating existing ones. Presumably it's written that way because it's designed to be used to be the global registry for all compiled protobufs. The way Prana uses it is to construct protobufs dynamically based on descriptors obtained externally.

The protobuf registration API thus should store descriptors into some other interface that can update existing descriptors and potentially construct protoreflect.Registry on the fly, or act as the protodesc.Resolver interface itself.

[mightyguava]

Splitting the unresolved tasks into other issues and closing this one since protobufs are working enough.