Introduce CloseableCoroutineDispatcher abstract class

[qwwdfsad]

* Alias it to ExecutorCoroutineDispatcher on JVM as the most appropriate candidate
* Add abstract classes to JVM and Native
* This class will be implemented by new dispathers for K/N new memory model

[qwwdfsad]

It also worth checking if we can make it experimental without propagating experimentality to ExecutorCoroutineDispatcher, will do

[dkhalanskyjb]

(Take my words with a grain of salt, as I wasn't on the design meeting for this and it's possible that these questions were already covered)
The main use case for this is #2558, right?

As implemented here, close() is like asking the dispatcher "hey, unload when you're done, okay?" and then just leaving. Is this really the behavior that we want? My assumption is as follows: close() will always be called after the users think they're completely finished working with coroutines. If so, it is unexpected that some jobs are still running or pending at the moment of call to close(). Maybe we could do awaitTermination here. Maybe we could also call shutdownNow and loudly complain if there were some pending tasks. In any case, I think that someone who calls close() on coroutine dispatchers will not be satisfied with just a "best-effort" solution to stop the dispatchers and would want to be notified in some way if there is some rogue job that prevents the code from being unloaded.

[dkhalanskyjb]

Suggested change

	* Invocations of `close` on already closed dispatcher have no effect.
	* Invocations of `close` on an already closed dispatcher have no effect.

[dkhalanskyjb]

There's ambiguity: it is stated above that close initiates the closing sequence, but doesn't necessarily close the dispatcher. I assume the two are considered equivalent here? If so, two ways to rephrase this that I see:

• Talk here not about closed dispatchers, but only about those "that already entered the closing sequence". Cumbersome, in my opinion.
• Clarify via a more formal additional sentence that calls to close are idempotent.

[qwwdfsad]

The main use case for this is #2558, right?

It is not, for that we have another solution, #2915

The main use-case is #2914: we want to introduce newFixedThreadPoolContext() and newSingleThreadContext to concurrent source set (shared between Native and JVM). They represent closeable resources on both platforms, thus we need an abstraction over the dispatcher that represents closeable dispatcher and, well, can be closed.

Apart from that, we already have ExecutorCoroutineDispatcher.close (CloseableCoroutineDispatcher is an alias to that) since the 1.0.0 release and it seems to be accepted quite well, I'm not sure we want to break things here.
awaitTermination cannot be implemented on top of the Executor (only on top of ExecutorService) and it also would be nice to avoid one more public hierarchy for "dispatchers that can only be closed" and "dispatchers that can also be awaited".

[dkhalanskyjb]

Ah, ok. All my points are invalid if unloading the dispatchers is not the point of this.

[qwwdfsad]

PTAL one more time just to double-check experimentality

[dkhalanskyjb]

Makes sense.