Add support for `DRUPAL_PACKAGE_MANAGER_NOT_SUPPORTED_HELP_URL` env variable

[Schnitzel]

Drupal is working on adding automated updates to Drupal Core https://www.drupal.org/project/automatic_updates which basically means Drupal will try to update it's code base automatically when a new version of Core or Modules exist.

Lagoon does not have support for this, for 3 reasons:

1. Automatic Updates need write permissions in the filesystem to actually update the code base, our containers don’t allow you to change the filesystem in a running container, so the upgrade will fail.
2. Even if Lagoon would allow a customer to change the file system you could not commit back the code into the git repo of the code base (as in the container you don’t have git commit access)
3. with containers the application code base actually exists multiple times in each container (nginx, php, cli), to properly upgrade this you would need to upgrade all 3 places at the same time (!) which is impossible

Therefore Lagoon cannot support this. Drupal actually will check for write permissions first before attending an update and will fail, so it can't happen that sites are in a weird state. Nonetheless Drupal added a functionality that allows a Hosting Platform to disable the auto update functionality (actually all of package manager functionality) and show the user a link to documentation why this feature is not supported, see https://git.drupalcode.org/project/automatic_updates/-/commit/dee9269

In short this involves setting an env variable DRUPAL_PACKAGE_MANAGER_NOT_SUPPORTED_HELP_URL with an URL to a documentation that explains why this does not work.

We should add support for this in Lagoon. I'm not sure how exactly we want to set this env variable: Inject in lagoon-env Config Map? One thing to keep in mind: technically auto updates work in local development environments as there the issues 1-3 above are not existent (write access exists, git access exists, code base is shared through the host), so adding the env to the Lagoon Base Images might not be the best solution.

[rocketeerbkw]

Attempting to test automatic updates, I've found a number of other reasons why it can't run OOTB:

• The underlying system which does the updates is the package_manager module which has a dependency on composer. Since we only install composer in the cli image, Drupal running in the php container can't actually do the updates

  

• There is also a requirement for rsync to be installed in the php image which it isn't by default

• The package_manager module doesn't work on alpine linux https://www.drupal.org/project/automatic_updates/issues/3395782

• Any module that scaffolds files will disable package_manager

  

• Even running locally, it's unclear what the permissions are given that we map files to the host OS. When composer runs initially it could be root which causes a bunch of errors for automatic_updates since it then can't update the files at runtime