Backend refactoring proposal: Step 1. multipackage monorepo

[JannikStreek]

Context: As proposed by @SamTV12345 I had a look at #5812 . To avoid creating a new massive PR that gets stuck I would propose to take small steps instead. As a start, I looked at the plugin architecture and especially this quote from the mentioned PR:

get rid of the symbolic link ep_etherpad-lite; instead use npm link ep_etherpad-lite in the root directory to build a package.json file and install all the dependencies in node_modules, incl. the link to ./src

Status quo: The node_modules folder in the root directory essentially works as a plugin directory but is not a "real" npm node_modules folder (as no package.json exists to control it). The src folder is sym linked (already hardcoded but otherwise also done in src/bin/installDeps.sh) and further plugins source code can be dropped in there. Otherwise plugins can also be installed during the build, when given in ETHERPAD_PLUGINS env variable. The folder is then scanned within the plugins.js file for content.

My opinion: Despite being obviously a problem for the upgrade (as mentioned in the PR) I see multiple issues with the current architecture:

• First, the root level has no package.json file, so having only a nodule_modules folder is confusing and also results in a couple of hacks. For instance, installing the build time plugins inside the Dockerfile (line 112) is done using —no-save and the plugin detection scan has a long comment why certain parameters have to be used (see src/static/js/pluginfw/installer.js, line 45)
• Kind of a circular dependency: The current project is itself a plugin (ep_etherpad-lite) and is basically requiring itself.

Refactoring proposal: I would suggest to split the project basically in two parts but keeping it in one repository (multipackage monorepo). The root project simply holds the bin folder and installs the ep_etherpad-lite plugin (through package.json) which is located in the src folder (could be renamed to ep_etherpad-lite). This can be achieved easily using pnpm workspaces:

- package.json # holds workspace reference to ep_etherpad-lite
- bin
- ...
- ep_etherpad-lite (formerly src, we can keep also the name src for now)
    - package.json
    - …

At a later point in time, one could optionally also extract at least the sever scaffold structure (server.ts, express, ...) and the plugin system.

This results in a cleaner setup and gets rid of the sym link (well at least doing it by hand as pnpm/npm workspaces also use sym links under the hood). Also, new plugins can be easily added either via the root package.json or by using npm link, if the source code is available locally (e.g. because a plugin is tested locally).

I started with a small prototype that leverages workspaces and roughly shows how the setup works: #6170

If the direction is agreeable, I am happy to create a PR.