Multiplayer

[Macroz]

Mostly working draft for #2622

Some open issues:

• File upload is broken, needs investigation.
• There should be a config whether the applicant only can send the application or can members also.
• Config should exist whether members are allowed to edit or just view.
• Test in browser for multiple people editing and seeing the changes.
• Test API security
• Test the long poll functionality to make sure it keeps working.
• Use the same keepalive tactic we have in REMS arleady with the subscription to stop it when the user is not actually doing anything (optimization).
• Long polling will cause the REMS browser app to reconnect and re-authorize automatically but keepalive would fix this?
• Same user has many tabs open. Should it have one or many names displayed?
• Check the UI terminology i.e., Users vs. Applicants vs. ?
• If reloading the application, it takes one long poll cycle to get the other clients. We could load these immediately.
• There is some internal naming that could perhaps be improved with form-id vs. form/id, and field-id vs. field/id.
• Manual mention.
• Overall, implementation could also include a refactoring of keepalive together with this subscription mechanism so that there exists only one "backchannel" to communicate with REMS:
• The design uses long-polling because it is fool-proof and simple. A WebSocket API or SSE is possible too, but maybe not worthwhile at the moment. At least the risks with this API style are minimal.

Checklist for author

Remove items that aren't applicable, check items that are done.

Reviewability

• Link to issue
• Consider adding screenshots for ease of review

Backwards compatibility

• API is backwards compatible or completely new
• Events are backwards compatible or have migrations
• Config is backwards compatible
• Feature appears correctly in PDF print

Documentation

• Update changelog if necessary
• API is documented and shows up in Swagger UI
• Components are added to guide page
• Update docs/ (if applicable)
• Update manual/ (if applicable)
• ADR for major architectural decisions or experiments
• New config options in config-defaults.edn

Testing

• Complex logic is unit tested
• Valuable features are integration / browser / acceptance tested automatically

Follow-up

• New tasks are created for pending or remaining tasks