[core] Remove grpc client thread number

[dentiny]

This PR resolves #49240

From my understanding:

• Threads are allocated at server side, by default each grpc request is handled by a different thread, coming out of a threadpool; the quota used in the grpc client constructor caps the max num
• On client side, apart from the polling thread (all sync grpc calls are built upon async one, which bakes an eventloop in a polling thread), I'm not aware of any conditions which require extra threads inside of client library, since it leverages http2 and io multiplex underlying

Performance test commit: d631f40
Performance dashboard: https://b534fd88.us1a.app.preset.io/superset/dashboard/19/?native_filters_key=LosP6LvuIiFtoQC_7slPcR-99euapUl2IU9rKLMjMntJgZz6LtYnyGly9fhI5oJ1
Average perf metrics value for latency: 16.832991340999996

Release test for this branch: https://buildkite.com/ray-project/release/builds/27984#0193bd0f-098b-4df9-9504-e23263a6b30f
Perf latency metrics for this PR: 14.782282467999991

[dayshah]

change places where this constructor is used too? Are the other uses casting num_threads to bool rn?

[dentiny]

I don't find it used anywhere via simple grep, but I will wait for CI results.

[dayshah]

ray/src/ray/rpc/object_manager/object_manager_client.h

Lines 51 to 52 in 2385b18

	grpc_clients_.emplace_back(new GrpcClient<ObjectManagerService>(
	address, port, client_call_manager, num_connections_));

this seems to be the constructor used here, i think now it's just using one above this one instead and implicitly coverts the int to a bool

[dentiny]

Good catch! Updated.

[jjyao]

How do we make sure we removed all usages of this constructor and didn't accidentally call the one above by converting int to bool?

[dentiny]

I made an extra test PR: #49283, which throws exception on the grpc client overload removed in this PR; and it turns out all CI tests pass.