Implement/service config

[nathanielford]

Motivation

ServiceConfig requires an internal representation that we can de/serialize.

Solution

This CL implements the ServiceConfig struct and necessary plumbing for de/serialization. In a follow-on CL(s) we will be adding the plumbing to fully utilize the ServiceConfig, including adding the option to the Channel builde, passing it to the load balancer tree for utilization, and interactions with the Name Resolver.

Notes

• Serde-specific data transfer objects were created so that we weren't exporting foreign types, and giving us options for de/serialization without breaking users going forward.
• Initially this PR included deserializing stringified u32 types, in concordance with C++ and Java. We may re-implement this going forward, but for now we are forcing the json to have valid raw integers. The concern here is making sure bugs don't arise because macro annotations get missed on edits. We may decide this is stable enough that we don't care, or we may have an internal type (i.e. GrpcU32) like we do with GrpcDuration.

[dfawley]

Thanks for the updates. The Duration stuff LGTM; glad we can do this without needing to annotate every instance of the field individually.

[dfawley]

Should literally every field be in an Option<>? Or what is the failure mode supposed to be if a single field fails to parse?

[nathanielford]

If deserialization fails, it should return an Error, which will be bubbled up appropriately. Probably better to fail here directly I think?

[dfawley]

I think I looked at everything, and I think this the only problem. It is valid to have a fully empty method_config.name. See this example:

https://github.com/grpc/grpc-proto/blob/99135b19189588fcc787acb84cff27991787473d/grpc/service_config/service_config.proto#L58

However, if service is unset, then we must validate that method is also unset.