Consider changing env vars so that all are expected to be prefixed with SHLINK

[acelaya]

For some time, Shlink can be configured via env vars.

This feature started as a way to provide configuration for the docker image, which incidentally made them have too generic names in many cases, because there was no risk of conflicting.

Later this mechanism was extended to be supported outside of docker as well. This means you could have other apps running on the same environment, with env vars of their own which could potentially conflict with Shlink ones.

Because of this, it would be good to change Shlink so that all its env vars are prefixed with SHLINK. For example:

• PORT becomes SHLINK_PORT.
• DB_DRIVER becomes SHLINK_DB_DRIVER.
• DEFAULT_DOMAIN becomes SHLINK_DEFAULT_DOMAIN.
• RABBITMQ_HOST becomes SHLINK_RABBITMQ_HOST.
• Etc.

This should be done in a backwards compatible way, so when loading nev vars, we should try to fall-back to their non-prefixed version if the prefixed one is not found.

The non-prefixed ones will become deprecated, and removed in Shlink 4.0.0 5.0.0

This change also affects the installer, which generates a map of options that are later promoted as env vars by shlink-config's EnvVarLoaderProvider. There are two ways to address this:

• The Shlink installer starts generating prefixed options.
  • That is a breaking change if someone tries to use a newer version of the installer with an older version of Shlink. Unlikely, but not impossible if someone tries to build Shlink from sources, due to the lack of locked dependencies.
  • The installer could introspect Shlink's config to know the version, and prefix the options or not based on that.
• EnvVarLoaderProvider accepts an optional prefix that is prepended to options before promoting them to env vars, unless they already start by that prefix.
  • This change is backwards compatible, and will continue working if eventually or accidentally the installer includes the prefixes.

There are some edge cases, like SHELL_VERBOSITY. This env var is referenced in many places to help debug Shlink, but it's not directly consumed by Shlink itself, but one if its dependencies.

Should SHLINK_SHELL_VERBOSITY be supported as well, mapping it to SHELL_VERBOSITY if defined? Or should this one have a special treatment?