Reorganize modules to support all targets in pure Kotlin modules

[joffrey-bion]

Background

Currently the krossbow-websocket-core module defines different things:

• the common websocket API (WebSocketClient, WebSocketConnection)
• some common core classes (like an adapter from callbacks to channel)
• basic adapters of the Krossbow API for each supported target, without transitive dependencies (adapting the browser's WebSocket on JS, the JDK11 client for the JVM, and Apple's NSURLSession on darwin targets)
• a multiplatform WebSocketClient.Companion.default() factory function that returns the adapted built-in implementation on each supported target

The krossbow-stomp-core directly depends on krossbow-websocket-core (it obviously needs this common API), but also provides a no-arg StompClient() constructor relying on the default() websocket factory function.

The problems

Problem 1: Limited platform support

The websocket API part cannot be published for all targets because adding other targets would require providing a default built-in implementation for them as well (due to the default() expected function).

In turn, krossbow-stomp-core cannot support all targets either, even though it is implemented 100% in pure Kotlin, because it depends on krossbow-websocket-core. It also has a similar problem because it relies on the default() websocket factory function.

One major drawback is that users cannot use any Krossbow module on targets that have no Krossbow built-in ws implementation, even if they want to provide their own implementations for those targets. Worse, they cannot use Ktor websockets on such targets even though Ktor supports them, because we can't release the Ktor Krossbow adapter on those targets due to the absence of Krossbow's websocket API for those targets.

Problem 2: unnecessary classes in 3rd party adapter modules

The built-in adapters from krossbow-websocket-core are present in krossbow-websocket-ktor and similar modules, even though most of the time they are not used (the point of the other modules is to adapt other things than the platform's built-in clients).

The solutions

Extract the multiplatform default() factory function along with built-in adapters into a new module. Possible names:

• krossbow-websocket-default (emphasis on the fact that there is a multiplatform default() method that provides something sensible on every platform)
• krossbow-websocket-builtin (emphasis on the fact that the implementation is built-in the current platform)
• krossbow-websocket-zerodep (emphasis on the fact that there is no transitive deps)
• krossbow-websocket-simple (because why not?)

Extract the no-arg StompClient() constructor (which uses the multiplaform WebSocketClient.default() method) from krossbow-stomp-core into its own module. Possible names:

• krossbow-stomp-default (looks like a good default choice, and also provides a "default" constructor)
• krossbow-stomp-builtin (hints at the fact that we use built-in implementations of WS from the platform, but unclear for this module)
• krossbow-stomp-simple (because why not?)
• krossbow-stomp (hints users towards using it by default, but the difference with krossbow-stomp-core would be quite unclear)

Intermediate source set doesn't cut it

We could declare an intermediate source set like commonDefault in both krossbow-websocket-core and krossbow-stomp-core to hold the websocket default() factory function and the StompClient() no arg constructor, respectively. This would neatly bring the default() function to user projects when they have the right subset of targets, and not in projects that need more platforms.

Why it's not great:

• This doesn't solve the problem of having the built-in websocket dependencies on the Ktor adapter's classpath (and other similar modules).
• People might not understand why they don't have access to the no-arg StompClient() constructor or the WebSocketClient.default() factory function