[Streaming]relink grpc/absl for streaming.so

[ashione]

To avoid exporting thrirdparty library symbol globally, these absl/grpc libs have been applied in _streaming.so.
Side-effect:
Static variables might be uninitialized if core worker lib and streaming lib both use them.

Why are these changes needed?

Related issue number

Checks

• I've run scripts/format.sh to lint the changes in this PR.
• I've included any doc changes needed for https://docs.ray.io/en/master/.
• I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
• Testing Strategy
  • Unit tests
  • Release tests
  • This PR is not tested :(

[jovany-wang]

Static variables might be uninitialized if core worker lib and streaming lib both use them.

What's the case that both streaming.so and coreworker.so use the same static var? Both of streaming lib and coreworker lib introduce it in one thirdpary?

[ashione]

Static variables might be uninitialized if core worker lib and streaming lib both use them.

What's the case that both streaming.so and coreworker.so use the same static var? Both of streaming lib and coreworker lib introduce it in one thirdpary?

In our internal production version, I try to bind ray streaming so library with ray_common deps, but two different statatic variables in _streaming.so and core_worker.so. It cannot find correct value within same symbol if core worker enable stats metric module. For example:

grpc.enable_xxx() # Set in coreworker lib
grpc.get_xxx() == True # Get in coreworker lib

# But it's disabled in other static linked library.
grpc.get_xxx() == False

@jovany-wang

[jovany-wang]

Should we load coreworker dynamically in streaming?

[ashione]

Should we load coreworker dynamically in streaming?

Althought we load core worker library dynamically, no exported symbol makes streaming lib unaccessable.

[jovany-wang]

Isee.

[jovany-wang]

Windows failures are unrelated, merging this.