Ensure EmitUnpopulated=true for REST responses

[NathanBaulch]

I'm new to ConnectRPC and have just finished migrating my grpc-gateway server across to Vanguard.
One regression I'm seeing is related to protojson's EmitUnpopulated which appears to be true in Vanguard but false in the underlying Connect handler. The latter is the response marshaler that's actually being used at runtime. I've done some debugging but there's a lot going on in transcoder.go.

What is the correct way to make sure REST protocol responses are always encoded with the Vanguard JSONCodec?

As far as I can tell, the "Accept: application/json" header is forwarded through and the Connect handler obliges with its own JSON marshaler. I could replace that underlying codec but it seems like there should be a way to accomplish this in the Vanguard layer with no impact on non-REST requests.

Perhaps there's some way to register a "json+emitunpopulated" codec and have Vanguard rewrite the request somehow to instruct the underlying connect handler to use this codec?

[emcfarlane]

Hi Nathan, the vanguard handler will respond in the protocol the client initiated. We follow the protocols defaults for the base settings. So if the protocol is detected as connect it will respond not in a REST style but as the connect default. We might in the future add default HTTP bindings (see #124) but this isn't supported as of now.

This sounds like we are not unmarshalling/remarshallling the JSON codec when handling the request. This is an optimization to avoid unnecessary marshalling. Theres a couple of solutions. Right now you could change the Codec default in the server, see github.com/akshayjshah/connectproto. You could also force binary encoding for the server, so the transcoder would unmarshal the binary encoding, and re-encode as JSON. We might want to have this an an option to avoid this optimization but the output is just a stylistic difference.