Log regex compilation as error

[ALX99]

What does this PR do?

Logs an error message instead of debug if we fail to parse DD_TRACE_OBFUSCATION_QUERY_STRING_REGEXP

Motivation

Better UX. It should be easier for users to find out that they provided a regex that was invalid

Reviewer's Checklist

• Changed code has unit tests for its functionality at or near 100% coverage.
• System-Tests covering this feature have been added and enabled with the va.b.c-dev version tag.
• There is a benchmark for any new code, or changes to existing code.
• If this interacts with the agent in a new way, a system test has been added.
• Add an appropriate team label so this PR gets put in the right place for the release notes.
• Non-trivial go.mod changes, e.g. adding new modules, are reviewed by @DataDog/dd-trace-go-guild.

Unsure? Have a question? Request a review!

[darccio]

@ALX99 Thanks for your contribution. You can achieve the same result setting DD_TRACE_DEBUG=true. As you are already using the environment variable DD_TRACE_OBFUSCATION_QUERY_STRING_REGEXP, this solution suits your use case.

In general, we tend to favour debug logs instead of error logs for configuration issues.

Does it work for you?

[ALX99]

Hello @darccio ! Yes, of course this works for us!

From a user standpoint, I thought it would be desirable to log it as an error.
If I, as a user am explicitly configuring something, and I make a mistake that causes the configuration not to apply, I would expect that it would be logged as an error.

To me it feels a little bit strange, needing to turn on debug logs just to be able to confirm that there was no error in the configuration that I set. But if this way is desirable to the dd-trace-go maintainers, I am in no position to argue.

Please close this PR, in case this change is seen as undesirable 😄

[darccio]

@ALX99 It's a fair point of view. We are discussing this internally, as some colleagues have found your comment interesting. We'll keep the PR open in the meantime.

[darccio]

@ALX99 We've decided to accept the proposed PR. Also, we'll review our logging statements to make sure they are coherent.