#150 #141 Rework dependency injection architecture

[tortmayr]

#150 Rework DI architecture
No longer use one global injector per application connection. Instead use a global server injector and dedicated child injectors for each client session. This removes a couple of flaws/downsides we had with the current approach. To achieve this the GLSPModule has been split into two separate modules. The ServerModule provides the bindings for base infrastructure & networking (used for creating the server injector) while DiagramModules provide language & session specific bindings (used for creating the session specific child injectors).

The main benefits are the following:

• Each session now uses its own ActionDispatcher this means action messages intended for different client sessions can now be handled in parallel. Previously they were processed one after the other essentially creating a bottleneck.
• One GLSPServer can now handler multiple different diagram implementations. The diagram language specific bindings are provided with a DiagramModule. When creating a new client session injector the corresponding DiagramModule is identified via the given diagram type. This can for instance be used in UML-GLSP to provide all different diagram types (class,package,state machine etc.) with one server.
• Apart from the initial "process" method it is no longer necessary to keep track of the diagramid/client session id. Each session has its own instances of action handlers, operation handlers, model state, diagram configuration etc. and the clientId no longer needs to be passed as method argument. In addition, provider classes with the purpose of mapping a class instance to the correct digramId like ModelStateProvider or the DiagramConfigurationRegistry are now obsolete and have been removed.
• It is now possible to create stateful action/operation handlers. Previously handlers had to be stateless because they were reused for all client sessions. Now each session has its own set own set of handlers .
• Use the new approach of injecting optionals (provided by Guice 5) instead of binding NullImpls.

Note that this PR only provides the DI architecture rework. Existing API whose functionality does not break after the rework as not been touched yet even tough there a various aspects of the existing API that can now be simplified/improved. For instance, with the new approach the Action/Operation Handler API can be simplified. It is no longer necessary to pass the model state argument as part of the interface methods (see also #120). I have identified some major aspects of the API that can be improved (corresponding issues will be created after this PR is merged).

#141 Refactor ClientSessionListener API

• Extract listener methods for server connection from ClientSessionListener interface into own ServerConnectionListener interface. Server connection listeners are handled directly by the GLSPServer.
• It is now possible to define a set of clientIds for which a listener should be registered when adding a new ClientSessionListener to the 'ClientSessionManager`.
• The DefaultGLSPClientSessionManager now autodisposes all ClientSessionListeners for the corresponding clientSessionId when a session is disposed.
• Improved null-checks: The client session manager now checks for disposed listeners (i.e. null values in the map) and removes them before notifying (i.e invoking a listener method) them.

Miscellaneous

• Reduce public API exposure. Interface implementations that typically are not expected to be customized by implementing projects haven been moved to the internal API.
• Improve documentation. Add javadoc for all newly added interfaces and relevant public classes. Also improve documentation of some existing components.
• Merge GLSPServerStatusAction and ServerStatusAction
• Introduce ModuleUtil class with provides the functionality to mixin modules similar to how it is done in Xtext.
• Remove uncessary .gitkeep file.
• Rename DefaultGLSPServerLauncher to SocketGLSPServerLauncher
• Rename ClientOptions to ClientOptionsUtil to conform to the standard naming scheme for util classes
• Follow Guice best practices and document all public bindings of a module

Fixes eclipse-glsp/glsp/issues/150
Fixes eclipse-glsp/glsp/issues/141

[tortmayr]

Here is a little illustration of the new injection approach:
Instead of using one global injector per application the Injection-context gets split into a a global server injector per application and dedicated child injectors for each client session. The server injector only provides infrastructure and networking classes. Diagram language and session specific bindings are contributed by the client session specific injector.
Instead of using one global injector per application connection, t Instead use a global server injector and dedicated child injectors for each client session.
The server injector is created when the client application initially connects. When the server receives a new InitializeClientSession request it delegates to the ClientSessionManager who than create a new ClientSession. The client session itself contains the client session injector and exposes the ActionDispatcher so that the GLSPServer can delegate incoming action messages to the action dispatcher of the corresponding client session.

[planger]

Excellent job! Code looks great and clean, everything still works as expected.
I'm looking forward to how we can now make the handlers more flexible in terms of API!

[planger]

Should we rename that to DiagramGlobalSingleton?

[tortmayr]

Or maybe DiagramTypedSingleton? To make it more clear that these scope provides Singletons in the context of the diagram type

[planger]

Yes sure, I'd prefer DiagramTypeSingleton a bit over DiagramTypedSingleton or DiagramGlobalSingleton.

[tortmayr]

Thanks for your Review Philip 👍 . I have addressed your feedback and also rebased the change to resolve conflicts.
As mentioned inline the @Inject annotations needs to present even if additional custom annotations are used. I reverted the corresponding change that you did in a0d82f2.

[planger]

Thanks, looks great!