runtime: set type_url for storage Any requests

[daviddrysdale]

The prost protobuf library does not support message descriptors, so
encapsulated Any messages from Nodes cannot fill in the type_url
field. However, the C++ protobuf library code that unpacks an Any
message into a specific protobuf message type requires this field
to be present and match.

Work around this by assuming that storage requests are of the correct
type, and modify the Any message to set its type_url field
appropriately.

Checklist

• Pull request affects core Oak functionality (e.g. runtime, SDK, ABI)
  • I have written tests that cover the code changes.
  • I have checked that these tests are run by Cloudbuild
  • I have updated documentation accordingly.
  • I have raised an issue to
    cover any TODOs and/or unfinished work.
• Pull request includes prototype/experimental work that is under
  construction.

[daviddrysdale]

To unblock #829

[daviddrysdale]

Heh: #831 unblocks #829 which fixes #668 which unblocks #764 which will unblock #757 and #801 , the latter of which fixes #729 !

[tiziano88]

I was thinking to just replace that with a bytes field actually, since in general the type information is not actually coming through from gRPC, just bytes. Also strictly speaking IIRC gRPC is supposed to work with arbitrary serialization formats (though in practice I have not seen anything other than protobuf). Also it would help transform the gRPC server pseudo-node into a generic HTTP server pseudo-node, which is something I would like to be able to do (and the Rust-based version is pretty close to it already). WDYT?

[daviddrysdale]

My previous feeling was that we should stick to Any, because the type indicates clearly that the contents are expected to be a serialized protobuf, and moreover it's the canonical way to encode an arbitrary protobuf message.

But the latter is less relevant if we're no longer capable of filling in the type_url part of Any, and the former could be accomplished by a comment (// contains a serialized protobuf message, whose type should be deduced from the request's method_name) rather than by using a type. So plain bytes seems reasonable now.

(Must admit I'm slightly surprised to hear you arguing for less use of a type system though!)

[tiziano88]

Anyways let's go ahead with this to unblock things, we can follow up with the refactoring to bytes separately.

[tiziano88]

FYI I am looking into the bytes refactoring.