Tcs is exhausted when external thread-id changes frequently

https://github.com/intel/linux-sgx/blob/50d5bec588674c22b60eaf5a5dea0368c7cde97f/psw/urts/tcs.cpp#L545-L558
The scenario is untrusted using grpc to process request in parallel, which uses a dynamic thread pool, and the untrust thread id is always changed. Each grpc request will do an ecall. using the binding policy, tcsnum=8, I found two problems:
1. untrust grpc thread A is bound to trust thread X and is doing ecall. If other threads trigger garbage collection, the find_thread call does not always find A, but the reference to X is not 0. In this case, garbage collection will directly deletes X, so a tcs is not available. This problem is mainly caused by the frequent creation and destruction of grpc threads, which makes find_thread unreliable. When I ran for 39 hours, all tcs were unavailable.
2. When the grpc thread has finished ecall and is no longer used, the grpc thread pool does not reclaim this thread in time. In this case, the bound trust thread cannot be recycled in time. As a result, I set tcsnum=8, but often only 6 or 7 can be used in parallel.

Start with psw/urts/tcs.cpp lines 545-558, then trace find_thread and the garbage-collection path involved when external gRPC thread IDs change. Reproduce the dynamic-thread-pool scenario and verify that bound trust threads are not deleted prematurely and that configured TCS entries become recyclable after ecalls finish.

Written by the indexing model from the issue text.