chore: proper fallback value for boolean "bogus" options

[david-luna]

Description

When refactoring our configuration tests to run them in separate processes (#3762) an unwanted behaviour was discovered when a "bogus" boolean value is set in the configuration. This is when the value is not any of true, false, "true" or "false".

Regarding bogus values the spec says

If an invalid value for a configuration option is provided (for example: breakdown_metrics="yes" or apiRequestTime="1h") then the agent MUST ignore the value (falling back to a config source with lower precedence) and SHOULD emit a log warning about the ignored value.

The node agent logs the warning but instead of falling back to a config source with lower precedence the value gets resolved to undefined ignoring sources of lower precedence like the defaults. As an example this behaviour with defaults would be okay for the options with false value as default (contextPropagationOnly, disableSend, errorOnAbortedRequests, opentelemetryBridgeEnabled, useElasticTraceparentHeader, usePathAsTransactionName) but not for options with dafault value set to true (active, breakdownMetrics, captureExceptions, captureHeaders, centralConfig, instrument, instrumentIncomingHTTPRequests, spanCompressionEnabled, verifyServerCert).

As a example we have this test that sets a bogus value for ELASTIC_APM_ACTIVE env var. this value wins over the other sources and when resolved we get undefined resulting in the agent being inactive.

apm-agent-nodejs/test/config/config.test.js

Line 345 in 0e3e002

// XXX: normalization turns this value to `undefined` because "bogus"

Possible approach

The agent should keep reference of the options provided from all sources instead of squashing them into a single object. then the normalization process should be aware of these sources to do the proper fallback if one option has a bogus value.

NOTE: as discussed internally this will be actioned when the test refactoring is done