grpc: add service config types and parsing

[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]

I believe we want this part to do a bit more -- and during parsing, not afterwards. Here's what we do in Go per config entry:

https://github.com/grpc/grpc-go/blob/4c226daff88f54441d70f710815e07b81fb162b2/internal/serviceconfig/serviceconfig.go#L82-L120

• Lookup the balancer in the registry; skip entry if doesn't exist
• Call it to parse the config; error all service config parsing if it fails
• Collapse to a single selected policy and its parsed config, not a vec.

It's nice to do this here instead of in the channel, because we have LB policies that have similar "child" fields that will want to do this exact same logic.

[nathanielford]

I've added a TODO around this. After looking at it, I'd rather do the 'mechanical' and plumbing stuff in the followup or in a smaller PR and keep this more bare bones. LMK if you think that's ok or if we keep good context by putting it here. It seems straightforward enough but would add additional files to the surface of this PR.

[dfawley]

I don't mind if you want to put the implementation in another PR, but then some of these abstractions I think are just wrong in light of the above, and should be deleted if they aren't updated.

1. ServiceConfig shouldn't have a pub fn lb_config(). ServiceConfig should be completely opaque externally (only parsed and passed around).

2. The LoadBalancingConfigSerde field should ideally (I think) parse a JSON array, but collapse it down to a single value: the first supported policy - it can also be empty if either the field is absent or if it contains no entries that are in the registry.