feat: No longer launch Go-based agent for compatibility/OTLP/AAP config

[litianningdatadog]

https://datadoghq.atlassian.net/browse/SVLS-7398

• As part of coming release, bottlecap agent no longer launches Go-based agent when compatibility/AAP/OTLP features are active
• Emit the same metric when detecting any of above configuration
• Update corresponding unit tests

Manifests:

• Test lambda function with logs showing compatibility/AAP/OTPL are enabled

• Logging

• Metric

[Copilot]

Pull Request Overview

This PR removes the fallback mechanism that would launch the Go-based agent when certain features (compatibility/AAP/OTLP) are enabled. Instead of falling back, the bottlecap agent now continues running and emits metrics to track these configuration scenarios.

• Modifies config parsing to no longer return errors for compatibility/AAP/OTLP configurations
• Adds metric emission capability to track configuration load issues with reason tags
• Updates all test cases to reflect the new non-error behavior

Reviewed Changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated 3 comments.

File	Description
bottlecap/src/config/mod.rs	Converts fallback function from error-returning to reason-collecting, updates get_config to never fail
bottlecap/src/metrics/enhanced/lambda.rs	Adds metric emission for config issues with combined tag support
bottlecap/src/metrics/enhanced/constants.rs	Defines new metric constant for extension failover tracking
bottlecap/src/otlp/mod.rs	Updates test cases to remove error handling expectations

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The #[must_use] attribute on the fallback function should include a message explaining why the return value must be used, such as '#[must_use = "fallback reasons should be processed to emit appropriate metrics"]'.

Suggested change

	#[must_use]
	#[must_use = "fallback reasons should be processed to emit appropriate metrics"]

[Copilot]

The #[must_use] attribute on get_config should include a message explaining why the return value must be used, such as '#[must_use = "configuration must be used to initialize the application"]'.

Suggested change

	#[must_use]
	#[must_use = "configuration must be used to initialize the application"]

[Copilot]

The cloning of keys and values in the extend operation is inefficient. Consider using references or owned values directly: combined_tags.extend(additional_tags.clone());

Suggested change

	combined_tags.extend(additional_tags.iter().map(|(k, v)| (k.clone(), v.clone())));
	combined_tags.extend(additional_tags.iter());

[duncanista]

I don't think we want to create a flusher here, why not reuse the existing one and let the flushing strategies handle this?

[litianningdatadog]

Acked

[duncanista]

Could we reuse this too? Create it, use it, then send it to the lifecycle processor? That way we don't allocate twice?

You won't get the right amount of tags after the invocation has occurred, like runtime

[litianningdatadog]

Acked

[duncanista]

Left one last comment and we should be good to go I think!

[duncanista]

LGTM – let's not merge until the next-next release, as we want this to be released on v86

[astuyve]

Finally!

[DarcyRaynerDD]

Maybe not for this release, but does this mean we can defer config parsing until after extension registration now? Will that save us any MS?

[litianningdatadog]

I doubt it based on my perception. At least the extension setup still relies on the configuration such as tracing log and FIPS.