take up too many tcp connections when watching on a huge number of services

[hehailong5]

I know we can watch on /v1/catalog/services to get notified if there is any changes on any service, and what's more, only one tcp connection is needed.
as the document states, the watch would return the full service list other than the changed ones. it is a huge overhead to find the changed ones and what's have changed at client side, since we have a large service set. we have to watch on /v1/catalog/service/{service name} for each service, but here comes another problem: each watch would take up a persistent tcp connection, the connection resource would soon run out. so, what's the best practice to watch the changes on a larger set of services?

[slackpad]

Hi @hehailong5 I think we could possibly add a new argument to these APIs to do some filtering on the server. Will take a look.

[slackpad]

This is similar to #2791, but applied to catalog.

[slackpad]

Closing this against #3657 which added HTTP/2 support, which works great for this use case.