Fix module context object re-usage in scripting engines

[rjd15372]

This commit refactors the scripting engine to support multiple cached module contexts per engine, rather than relying on a single cached ValkeyModuleCtx object.

Previously, having only one cached context object caused data races over the state stored in the context object, because it's possible that a script that is running for a long time to yield and the server event loop may call the scriptingEngineCallGetMemoryInfo function to get the scripting engine memory information, which re-uses the same cached context object. Another possible data-race is caused by the asynchronous scripts flush, which calls the scriptingEngineCallFreeFunction function in an background thread, and also re-uses the cached context object.

To address this, a cache array of module contexts was introduced in the scripting engine structure, with each slot dedicated to a specific use case—such as script execution, memory info queries, or function freeing.

[codecov]

Codecov Report

❌ Patch coverage is 70.37037% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.34%. Comparing base (de76586) to head (8c3f028).
⚠️ Report is 10 commits behind head on unstable.

Files with missing lines	Patch %	Lines
src/scripting_engine.c	70.37%	8 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #2358      +/-   ##
============================================
- Coverage     71.41%   71.34%   -0.08%     
============================================
  Files           123      123              
  Lines         67132    67163      +31     
============================================
- Hits          47942    47915      -27     
- Misses        19190    19248      +58     

Files with missing lines	Coverage Δ
src/scripting_engine.c	74.79% <70.37%> (-0.21%)	⬇️

... and 23 files with indirect coverage changes

🚀 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.

[madolson]

This theoretically should be backported, but we probably won't since the impact doesn't seem that high. This is not required for RC1 but should be merged before 9.0.

[enjoy-binbin]

I may not be familiar with the details, but overall LGTM.

[rjd15372]

@enjoy-binbin thanks for the review!

[madolson]

I didn't originally approve it because I was confused about the code call path. It's odd to me that we call engineSetupModuleCtx(engine, NULL); even on the non-module call path. I sort of understand the fix, but it sort of feels like there might be a more structural issue.

[rjd15372]

I didn't originally approve it because I was confused about the code call path. It's odd to me that we call engineSetupModuleCtx(engine, NULL); even on the non-module call path. I sort of understand the fix, but it sort of feels like there might be a more structural issue.

We setup a module context for all callback functions as a conservative approach because the callback implementation might use the context object for some unforeseen reason.