Make the gate closure more robust

[vlovich]

What does this PR do?

1. Avoid panicking if we drop one of the waiters. The panic was there to make sure to avoid a permanent deadlock because of the implicit linked list in notifying waiters that requested close.
2. Make the poll order of the closure irrelevant in terms of noticing that the gate closure happened.

Motivation

I was trying to write a unit test that tested that a certain ordering of events happened but the structure of the code made it impossible to test that the closure was noticed in 1 future before another (in theory I'm pretty sure it could still happen I think but the structure of the code made it difficult to test that ordering by just polling specific futures).

I've also been bitten by having a closure future that I wanted to not do anything with other than having done a soft gate closure request.

Related issues

Additional Notes

Checklist

[X] I have added unit tests to the code I am submitting
[X] My unit tests cover both failure and success scenarios
[] If applicable, I have discussed my architecture