Fragment Watch Response in server

[gyuho]

From #8188.

I saw at a scaled run where where are several (~2M) KV pairs associated with the same lease then upon lease expiry grpc-proxy (there are several issues using grpc proxy more on that later) / etcd will send around ~2M DEL watchresponse notifications, which will close the channel (with canceled not being set) and the Err being set to : error="rpc error: code = ResourceExhausted desc = grpc: received message larger than max (140103271 vs. 4194304)"

This also blocks #7624 if implemented using a keyspace-wide watch. The watch messages will need a fragmentation flag (probably want semantics like limit and more from Range) to indicate the events for a single revision are split over multiple messages.

Thinking about this issue more, limit semantics with some max n events would be something different from what's needed for the fix. Probably Limit would just drop more than n events and set More, but never deliver those extra events.

The fix here would involve a fragment boolean flag when creating the watch that will enable splitting up the large revisions (indicated with fragment set on the watch response when fragmented). This will also need client-side work to piece the results together.

Initial work in progress #9291.