Solve potential composer conflicts between the application and plugins

[jonasraoni]

Problem
Some plugins make use of Composer packages, which has the potential of getting in conflict with the packages loaded by the application.

With the presence of multiple Composer autoloaders, the last added one is the first one to be called (in our use case, plugins are the last).
If the plugin requires a package which is also required by the application, then once the plugin registers its autoloader, the plugin's version of the package will be loaded instead of the application one... If there are breaking changes between both versions, the application might be broken unexpectedly (if something has to fail, it should clearly be the plugin).

It would be good to find a solution that doesn't require many workarounds and that works both for official and userland plugins.

Ideas to improve the situation:

• Using the prepend-autoloader setting, will ensure the plugin's autoloader doesn't have a high priority, and decrease the probability of failures.
• Install packages, which are known to already exist at the application level, with the --dev flag, then we can filter them out when packaging the plugin for release.
• Including the plugin's autoloader only when needed will decrease the possibility of conflicts.
• Configuring Composer to look for additional composer.json files (https://getcomposer.org/doc/05-repositories.md#path), must be enough to solve conflicts within known submodules (the ones included within pkp-lib).
• The item above might be also used to prevent conflicts while updating/creating a new plugin.
• As part of the plugin tests, we could create a composer.json at the applications' root, which would just incorporate all internal composer.json files. The installation should succeed without conflicts. New builds in OJS/OPS/OMP should trigger the build for the plugins (if not possible, scheduled builds should be enough).

Ideas to fix (none of them are acceptable for me):

• With the help of https://getcomposer.org/doc/05-repositories.md#path, we could add a wildcard path to consider the plugins, then run a composer install (this way the other composer.json files would be included as a dependency) after downloading a plugin. If it fails due to conflicts, then the plugin should be disabled or the user should be warned (is the composer clean enough to be trusted? I remember about prompts to input a GitHub token, which would be a red flag).
• Sandboxing the plugin execution is doable, but sounds tough (too much job). A sub process/request could be employed to create the sandbox, and a common interface/bridge to pass/receive data should be implemented. As reviving all the state in a sub process isn't feasible, then in order to avoid decreasing the plugin possibilities, I think it would be needed to forward code to be evaluated in the caller 👀

[asmecher]

Motivating issues:

• #24 Updated the BagItTools package to fix issues under Windows pln#38
• Update PayPal plugin dependency guzzle adapter #8105

[jonasraoni]

I've just edited the text, I think I don't have anything more to add 🤔