Use proto optional fields for non required primitive object attributes.

[raphael]

This PR changes the proto files generated by Goa to take advantage of the optional keyword (re)introduced in proto 3.15.

In particular, this means that the generated transport data structure can make use of pointers for optional fields and therefore properly check for required fields.

Fixes #3159

[MichaelUrman]

Awesome update. Do you think it would be feasible and worthwhile to omit the 'optional' from fields that default to the zero value? That should avoid a pointer indirection in the pb struct and a branch in the goa server code that converts it.

[raphael]

Not sure I follow; would that be for fields that use Default in the design? If yes, then I believe we still want to specify them as optional and have Goa initialize them to their default value when unmarshalling if nil - that's been the behavior with HTTP.

[MichaelUrman]

Yes. I've used Default(0) and Default(""), etc. to avoid pointers in the server type struct. I do this mostly for ergonomics in fields that I'm not ready to require, including that the server struct won't change when we switch from Default() to Required().

My code is still insulated, but with this PR the underlying pb field type becomes a *int or *string, etc., for no expressive or performance benefit. Fields excluded from the protobuf message can be unmarshaled as nil and replaced with their zero Default, or unmarshaled as zero and converted, with no difference in visible behavior.

[raphael]

Using Default to avoid pointers in the service layer makes sense, in a way the idea is that the user "shouldn't care" about the transport layer (obviously it's great to have contributors that do :) ). As described earlier the algorithm uses pointers at the transport layer for fields with default values so that it can check for nil and in that case initialize the field with the default value before passing it to the service layer (where it's not a pointer anymore). This happens for payloads server side and responses client side and has always been the behavior with HTTP. It seems to make sense to keep that consistent with the gRPC transport.

[MichaelUrman]

Ok, thank you for considering. The symmetry with HTTP transports is nice, whereas I've used almost exclusively gRPC so I saw it as a change. I'll assume my performance concerns are premature until proven otherwise.