New protocol and generator options for asynchronous mutating traversal of messages

[FranzBusch]

Motivation

Our current Visitor protocol and generated traverse methods allow synchronous throwing traversal of the message fields. This works great for how our current serializers are working; however, often one wants to implement validators or transformers that mutate the fields of message. Sometimes this mutation is even asynchronous.

Modification

This PR adds a few things:

• A new AsyncVisitor protocol that allows to asynchronously traverse and mutate the fields of a message
• A code generator option to generate the new async traverse method
• Tests that validate that mutating async traversal is working

Result

We can now implement async visitors that mutate message fields.

[Lukasa]

Hrm, I'm really not sure this is a good idea. In general having async traversal of a message type strikes me as being a code smell: can you elaborate on why this is the right solution?

[FranzBusch]

Yeah I can give you a practical example. I have a library that talks with a gRPC service. Many messages to that service contain byte fields. For security purposes those byte fields can be encoded or encrypted. Since those byte fields can be arbitrarily nested it is easier and safer to implement this with a visitor than to hard code it for every single message type.
Now in my particular case the encryption can also be done by a remote service which lead me to making this visitor asynchronous.

Can you elaborate why you would consider this a code smell? I personally think this is a classic "what color is your function problem?" Of course most folks should use the synchronous visitor APIs where possible but it feels overly restrictive to not allow asynchronous visiting.

[Lukasa]

The sense in which it feels like a code smell is that it has taken a domain modelling problem and pushed it down into the serialization layer, rather than letting the serialization layer handle serialization and having your application use separate data model objects.

One of my pieces of supporting evidence here is that this visitor differs from the other not only in having async methods, but in having those methods be able to modify the structure being visited. That's a pretty substantial divergence from the existing Visitor protocol.

[FranzBusch]

I get your point but I would argue the current visitor pattern is overly focused on just catering for serialization needs whereas a visitor pattern is something generally useful. I agree that if you implement serialization with the visitor pattern this should be both non-mutating and synchronous. However, there are many more useful things to do with visitors such as applying common transformations to a whole message hierarchy.

I don't think we should over index on what the current visitor pattern since that is incredibly tailored to serialization. I tried to implement all of this outside of this library but to properly support it I need code generation and it felt right to me to expand the current visitor pattern with asynchronous and mutating visitors.