Make the ClientSession close method thread-safe

[jyemin]

Replace the volatile boolean with an AtomicBoolean to ensure that the side effects of the close method only execute once.

JAVA-5107

[stIncMale]

I have two concerns:

1. If we do the change, it may be worth explaining "why" in the code. Seeing code that deals with thread-safety in a class which must not be used concurrently is surprising.
2. This change patches one hole, but there are more. Both ClientSessionImpl and BaseClientSessionImpl have mutable plain fields, and do plain reads from / writes to them. If application code shares a session with multiple threads, and starts using it concurrently from those threads, that may lead to the session becoming corrupted (data races in Java are not UB, but are still bad, and race conditions are not a good thing either). Are we pathing this specific hole because the corruption it may cause spreads outside of a specific session?

[jyemin]

Are we patching this specific hole because the corruption it may cause spreads outside of a specific session?

Yes, as it causes persistent corruption of the session pool.

[stIncMale]

[optional]
It will be helpful to have a comment here explaining why synchronization exists in a class, instances of which must not be used concurrently. Such a comment may address

• why concurrency is relevant for instances of this class at all
• what specific problem is solved here
• why problems that concurrency may cause in other places of this class are disregarded

[stIncMale]

Approving because the only suggestion I left is optional.