Proto changes for aggregate stats.

[alainjobart]

This would allow re-using the current StreamHealthCheck to convey the
status of a group of tablets, between vtgate and l2vtgate (which will
be merged into vtgate).

[alainjobart]

@sougou This is what we talked about. What do you think? This seems minimal enough, but allows us a ton of flexibility...

(Note the individual fields of AggregateStats may change later, I'm not sure what we'll need).

Later on:

• TabletStatsCache can export these aggregate (easy to do). It will need to have a per-cell map, so its tablet status map may gain an extra map[string] layer with the cell.
• when l2vtgate exposes its queryservice, it can send these aggregate up (easy as well).
• both discoverygateway and l2vtgategateway can then expose these aggregates (easy as well).
• the srvtopo module can then use them to find the right targets in the right cells, according to a provided policy.
• vtgate can expose a queryservice interface, that connects its internal aggregates and discoverygateway to the outside. We can then retire l2vtgate.
• we can then implement a hybrid gateway, that would allow vtgate to have both local tablets, and remote vtgates.

None of these steps are hard, I'll work on them one at a time.

@demmer does that make sense to you too?

[sougou]

LGTM

[sougou]

lol. too late. missed the follow up questions.
But I agree with the changes (given that we discussed them).

[demmer]

Changes and overall approach sounds good to me too.