gh-769: Replace celix_tss usage with libuv key

[pnoltes]

This PR replaces the custom celix_tss implementation with libuv's uv_key_t API.

Current Status

This is a draft because the libuv TLS implementation lacks a destructor callback, which was previously used to clean up celix_err_t structures. Specifically, pthread_key_create allows a destructor registration, but uv_key_create does not (likely due to limitations in the underlying Windows TLS implementation).

The Problem

Without a destructor, celix_err_t structures allocated via malloc in celix_err_getTssErr() are leaked when a thread terminates.

Proposed Paths Forward

I have identified four potential strategies to address the leak:

1. Global Registry: Store created celix_err structs in a mutex-protected list. This list is cleaned up in a __attribute__((destructor)) function.

   • Cons: Memory only gets reclaimed at program exit, not thread exit. Memory usage grows linearly with the number of unique threads that have ever reported an error.

2. Thread Monitoring: Store thread IDs in the celix_err structure and provide a periodic cleanup function that uses pthread_kill(tid, 0) to check if threads are still alive.

   • Cons: High complexity and overhead; requires the Celix framework to maintain a background cleanup cycle. Also depends on pthread api.

3. Consume-to-Cleanup + Global Registry: Free the TLS entry whenever the last error message is consumed (popped). Additionally, include Option 1 to ensure any unconsumed errors are freed at program exit.

   • Cons: This introduces frequent malloc/free calls during error-heavy operations and theoretically does not solve the growing memory issues (if users are not consuming celix_err messages).

4. Platform-Specific Hybrid + (future) Global Registry: Use libuv keys for data access but register a "shadow" pthread_key on Linux/macOS solely to trigger a destructor on thread exit (using a #ifndef _WIN32). For Windows, this would fall back to Option 1 behavior.

Current Preference: Option 3.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 84.61538% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 91.51%. Comparing base (effe33a) to head (731d767).
⚠️ Report is 22 commits behind head on master.

Files with missing lines	Patch %	Lines
libs/utils/src/celix_err.c	84.61%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #818      +/-   ##
==========================================
+ Coverage   91.50%   91.51%   +0.01%     
==========================================
  Files         235      235              
  Lines       28686    30028    +1342     
==========================================
+ Hits        26248    27479    +1231     
- Misses       2438     2549     +111     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[PengZheng]

I am on vocation and will be back on the 19th. Then I will investigate on this.

[PengZheng]

I just studied the Win32 API of TLS, and found that it maps nicely to our current implementation:

Windows	POSIX
DllMain/DLL_PROCESS_ATTACH	CELIX_ERR_CONSTRUCTOR
DllMain/DLL_THREAD_DETACH	POSIX TLS destructor
DllMain/DLL_PROCESS_DETACH	CELIX_ERR_DESTRUCTOR

For Win32 support, implementing _WIN32 protected DllMain will be easy. For POSIX platforms, we just take advantage of the non-portable pthread_key_create. No need for global registry or extra thread monitoring mechanism.

WDYT? @pnoltes

Note that option 4 does not work because we cannot rely on a "shadow" pthread_key to cleanup other LTS according to man pages:

The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits.