Add option to configure cslb options without environment variables

[jenskueper]

Summary

Currently, configuring cslb is challenging, especially for applications that rely on it during tests. The primary limitation stems from the use of the cslb_options environment variable during the init phase. This approach provides minimal flexibility for pre-test configuration, as init runs before the test code.

Problem Statement

1. Environment Variable Dependence: Configuration via the cslb_options environment variable happens during init, limiting the ability to dynamically adjust settings during test execution.

2. Testing Challenges: Writing tests for applications using cslb becomes cumbersome because:

• Configuration must be predefined, making test setup less flexible.

• Changes to cslb behavior during tests are difficult to implement.

3. Code Maintainability: The current approach makes it harder to isolate and test functionality, reducing maintainability and increasing the risk of brittle tests.

Proposed Solution

Introduce configurable options via a new function, such as cslb.EnableWithOptions, or extend the existing cslb.Enable function to accept a configuration object or parameters. This would allow developers to:

• Configure cslb programmatically at runtime.
• Avoid reliance on the cslb_options environment variable.

[markdingo]

I understand what you want to achieve here. One complexity is that env variables are referenced by the started go-routines during the init() call. So to create EnableWithOptions() without breaking existing functionality would require that it stop and destroy the default cslb and re-create it with the provided options.

Another alternative is to create a v2 package which breaks compatibility by not performing auto-initialisation. In retrospect, performing auto-initialisation is pretty trivial to achieve for anyone who wants it by adding an init() function to their package. IOWs, I no longer think that providing auto-initialisation is that useful.