Deprecate frontend `DEPLOYMENT_ENV` and `SENTRY_ENV` in favour of site config's `SITE_ENV`

[sarayourfriend]

Problem

We have three runtime configuration variables relevant to our Nuxt site's deployment environment context:

• DEPLOYMENT_ENV which is bespoke and used only once
• SENTRY_ENVIRONMENT which duplicates DEPLOYMENT_ENV in use, and is held over from the old Sentry module's configuration, but used the same way in our in-house Sentry plugins
• SITE_ENV which is used by the various Nuxt SEO modules (sitemap, robots) and comes from the Nuxt "site config" module, which aims to be the canonical method for site-wide configuration shared between multiple modules (like the runtime/deployment environment).

Rather than using all three of these, we should switch to just SITE_ENV, not just because it's theoretically canonical (or at least meant to be), but also because it's the only one that isn't avoidable, due to it being the method for configuring the environment used by the Nuxt SEO modules.

Description

The process of migrating to the single SITE_ENV must follow the zero-downtime approach to environment variable changes described in our documentation: https://docs.openverse.org/general/zero_downtime_database_management.html#environment-variables

In order:

1. Update live environment configuration to set NUXT_SITE_ENV so it is available to deployed sites
2. Use site config's env in our code:
   1. Declare an explicit dependency on nuxt-site-config: https://nuxtseo.com/site-config/getting-started/installation
   2. Update the Sentry plugins to use useSiteConfig to retrieve the site's environment name
   3. Update the usages of DEPLOYMENT_ENV to use NUXT_SITE_ENV
      • This appears to just be server/utils/logger, which would ideally be converted to a nitro composable so it could also use useSiteConfig rather than reading the environment variable directly
   4. Deploy these changes to staging, verify them, then deploy them to production
3. Update the staging and production live environment configurations to remove SENTRY_ENVIRONMENT and DEPLOYMENT_ENV

Benefits

Reduce the number of duplicated environment variables to designate the runtime environment. Basically, solve a small part of the problem described in Nuxt site config's explanation of itself for this particular Openverse configuration over which we have control over.

Additional context

We could also refuse to accept the idea of the Nuxt site config module's extension of Nuxt's site configuration as canonical, and instead continue with the per-module configuration. For example, the Plausible and i18n modules do not support Nuxt site config, so while both refer to the site's URL, which could be retrieved from Nuxt site config's url option, we'd still need to define the site URL for each of these.

I tend to think it's worth trying to get movement towards Nuxt site config, mostly because these are variables that are so often shared between many modules, but it would be good to know if that's a general consensus or whether separate configuration for each module is the practice that will remain.

[sarayourfriend]

Actually, I think given Sentry is going to publish their own Nuxt module that will inevitably have its own configuration practice, I don't think this is a worthwhile change.

We could get rid of the DEPLOYMENT_ENV runtime variable if we wanted to, in favour of the site config one, but it might just be more trouble than its worth.