feat: Normalise environment string captured by app info package

[i-like-robots]

The FT may use multiple values across different platforms to indicate the environment that an app is running in. For example, AWS resources may be assigned an environment variable named ENVIRONMENT and the value "p" which is short for "production".

Follows #1112 (specifically this comment)

[rowanmanning]

Been thinking about this properly and I wonder whether this is a breaking change? We're currently doing no validation based on this and so it's possible systems have their own checks like appInfo.environment === 'p'. In the interest of fixing your specific issue I think there are a few options:

1. Add a new property to appInfo called normalizedEnvironment or similar and migrate to using this across the rest of the Reliability Kit packages. I don't love this because we're adding a maintenance overhead and I'd rather environment just be normalised.

2. Update the check within logger itself to search for production, prod, or p here. This would fix the immediate issue in the specific package you're having trouble with at the expense of a little more complexity.

3. Suck up the breaking change. I'm happy to do this however I'd like to lump in a few more changes, e.g. @sjparkinson is keen for us to rely on OpenTelemetry resource detectors for some of this stuff and appInfo is kind of due a bit of a rethink. So this option will take longer.

[sjparkinson]

Little bit tangental, but in my thinking on this I've felt that there's a missing attribute needed in order to allow us to normalise the deployment environment values (which I'd love to do). Something like deployment.environment_id so that you can still distinguish between different test environments or review apps etc.

[sjparkinson]

Oh looks like the deployment.environment attribute is being renamed too: https://opentelemetry.io/docs/specs/semconv/resource/deployment-environment/

Which does sort of leave room for a ID attribute or something.

[i-like-robots]

Been thinking about this properly and I wonder whether this is a breaking change?

If the property is a documented part of a public interface then I reckon this must be a breaking change 👍

Update the check within logger itself to search for production, prod, or p

This would resolve the issue we're having. As production/prod/p is as close to a standard as we get at the FT I assume this change would help implementors towards the expected behaviour and not be surprising.

Suck up the breaking change. I'm happy to do this however I'd like to lump in a few more changes

Then perhaps we do go for the above and a major version bump is saved for adding lots of value for people to upgrade to.

[rowanmanning]

OK cool 👍 then we'll do the following:

• @i-like-robots we'll get the logger to work with different production-like environments. I can do it tomorrow or feel free to PR it yourself if you have time!

• @sjparkinson I feel like we should talk about what ideal looks like for the app-info package. I don't know if we'll ever be able to rely fully on the OpenTelemetry resource detectors because we have lots of FT-specific stuff like the SYSTEM_CODE environment variable. Maybe standardising this stuff would be a useful piece of work? Then we can adopt whatever standard in the next major version of this package

[rowanmanning]

Closing in favour of #1373