Is your feature request related to a problem? Please describe.

Currently grpc_shutdown always spawns a dedicated detached thread (code) for executing the actual clean-up process. This is deliberately designed to prevent a self-join problem which can happen when grpc_shutdown is called from an executor thread. (Introduced by #17308, internal b/65754677 & b/119180212)

This behavior makes a subtle side-effect, a clean-up thread which outlives main thread. if the environment doesn't support this case, it could show an undefined behavior. Environments that we observed this problem; i) Visual C++ debug build which uses a debug-mode heap. (#22479) and ii) MSAN with Abseil Lock which uses a global variable (#21606)

This is mostly benign but it needs to be fixed to make unit tests using gRPC stable. Unit tests using gRPC under those environment tend to be flaky because of a detached clean-up thread.

Describe the solution you'd like

gRPC team doesn't want to introduce a new API only for this. We agreed that making shutdown work differently depending on whether it's called from the an executor thread or not. If it's free from an executor thread, it can freely work in a blocking manner, which solves this problem. Otherwise, it has to spawn the thread and it will join it later.

Describe alternatives you've considered

An easiest solution would be having a grpc_shutdown_blocking like api in gRPC C++ but it isn't ideal since users need to do extra step to use gRPC properly.