binder: Avoid potential deadlock when canceling AsyncSecurityPolicy futures

[HyunSangHan]

Move future cancellation outside of synchronized block in BinderClientTransport.notifyTerminated() to prevent deadlock if AsyncSecurityPolicy uses directExecutor() for callbacks.

Fixes #12190

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: HyunSangHan / name: HYUNSANG HAN (7138614, fc77da4, 9111970, c54cfff, 4d7ed66)

[jdcormie]

Help me understand the change here? All those cancel() calls still appear to come from inside the @GuardedBy("this") method notifyTerminated() method ...

[HyunSangHan]

Help me understand the change here? All those cancel() calls still appear to come from inside the @GuardedBy("this") method notifyTerminated() method ...

OMG! Sorry. I realized that I missed committing the actual fix!
I've just pushed the missing commit with the proper solution.

@jdcormie Could you please check the latest commit?

[HyunSangHan]

@jdcormie
I’ve addressed the review comments. :)

[jdcormie]

Woke up this morning with a small new concern: Would this PR cause us to declare the Channel terminated before all work we've enqueued on the offload Executor is complete (or cancelled) ? Take a look at how releaseExecutors() is called right after notifyTerminated() (the site of your changes) returns. Would this need to move into the shutdown path instead?

[HyunSangHan]

Woke up this morning with a small new concern: Would this PR cause us to declare the Channel terminated before all work we've enqueued on the offload Executor is complete (or cancelled) ? Take a look at how releaseExecutors() is called right after notifyTerminated() (the site of your changes) returns. Would this need to move into the shutdown path instead?

I agree with your concern. That's a very good point.
Since cancellation is enqueued on a separate thread, there's no guarantee that previously enqueued tasks have completed by the time we declare the Channel as terminated.
To address this fundamentally, notifyTerminated should ideally only be called once those tasks have finished.

That said, while thinking about ways to improve the code, two questions came up 🤔 :

1. Because cancellation itself is enqueued onto the executor and then handled asynchronously, even if we enqueue it earlier there's still no guarantee that the cancel operation will finish before notifyTerminated is invoked. The probability might be higher, but the guarantee isn't there.
2. Looking at releaseExecutors more closely, it does attempt to gracefully release resources once queued tasks complete. However, the method itself seems to return immediately without waiting for that completion. If that's correct, then simply moving releaseExecutors before notifyTerminated wouldn't necessarily solve the problem either.

Could you elaborate a bit more on what you meant by "move into the shutdown path instead"? I want to make sure I understand your idea fully.