*: fragment watch response by server request limit

[gyuho]

Replace #8371.
Address #8188 and #9294.

If watch response exceeds server-side request limit, it automatically splits watch response events and sends fragments over RPC. Clients still receive combined results, while the server-to-client dispatch happens with fragments.

Given this use case:

• --max-request-bytes '1572864' (1.5 MiB)
• Total 100 MiB watch response of 100 events; each event is 1 MiB
• clientv3.MaxCallRecvMsgSize is 1.5 MiB

Without this patch, fail with error code = ResourceExhausted desc = grpc: received message larger than max (10486027 vs. 1572864). With this patch, 100 events will be split over 100 fragmented watch response in server-side, then joined back in client before it being returned to the user.

Nothing changes from user's perspective.

[gyuho]

@SuhasAnand Can you give this a try?

The client receive limit error should be resolved via MaxCallRecvMsgSize in clientv3.Config (it was 4 MiB in <= 3.2.11). This PR splits events if combined response size exceeds server-side request limit. It's 1 watch send of 100 MiB vs. 100 watch sends (each send is 1 MiB).

[gyuho]

Did benchmark of total 120 MiB watch events, each of which contains 1.2 MiB value, so that server would split one watch response with 100 fragmented event:

watch with no fragmentation took 402.968818ms
watch with fragmentation took 441.428922ms

So, fragmentation would only have minimal overhead (mostly over the network), which is expected. There's no noticeable performance change and fragmentation will be disabled by default.

[SuhasAnand]

@gyuho lgtm. Thanks!