Server-side timeout mechanism

[sorra]

Is your feature request related to a problem?

Regarding #9684 , there have been multiple asks in the community for the server-side timeout. Servlets and database connections support timeout, so why gRPC does not provide it?
Our application is having such a problem. The grpc-java server usually runs workers in a ThreadPoolExecutor with a maximum size (infinite size is not better with the problem). If some server call instances run infinitely (e.g. having an infinite loop or in a waiting state infinitely), they will occupy some threads. And if this situation persists, eventually all threads in the pool will be occupied and no work can be done anymore, which results in a service downtime.
The client-side timeout only helps the client stop infinite waiting, it does not help the server stop infinite processing.

Describe the solution you'd like

Per the comment by @ejona86 #9684 (comment) , application developers can do it via a server interceptor. But it is not simple work for application developers, so why not provide an optional server interceptor in the grpc-java framework?

I have developed two classes for doing so: TimeoutServerInterceptor (the server interceptor) and ServerTimeoutManager (the global manager of the timeout queue). The timeout value is configurable and is only applied to unary calls because we do not expect a general timeout limit for streaming calls. I want to merge them into grpc-java codebase.
I have created a pull request #10360

My solution is as follows:

• Intercept each RPC method invocation:
  • before the invocation, wrap the current thread as a TimeoutTask and schedule the task after a delay that is equal to the timeout value;
  • after the invocation, invalidate the TimeoutTask because the invocation has been completed in time, so the thread will not be mis-interrupted when it is reused for another server call.
• If the invocation does not complete in time, the related TimeoutTask will be executed by the scheduler, and it interrupts the wrapped thread.
  Please let me know if my solution is suitable for merging.

Describe alternatives you've considered

Application developers can also perform AOP on their RPC method implementation to control how long a method executes. But this way: (1) is less easy to use, (2) requires an extra AOP framework, and (3) requires application developers themselves to guarantee every RPC method is AOP-weaved. It is also difficult to distinguish unary calls from streaming calls. So I prefer the gRPC native server interceptor solution.

Additional context