CORE-18961 fiber cache per sandbox

[simon-johnson-r3]

Prototypes having an instance of a fiber cache tied to a sandbox rather than one fiber cache as a singleton. This means closing a sandbox always results in the removal of the fiber cache for fibers which pertain to that sandbox and they can never be used against the wrong sandbox.

In summary, right now, fibers can be pulled from the singleton fiber cache after the sandbox in which the fiber classes are instantiated was evicted from the cache. Cache eviction listeners don't work as a solution to this in the case where the sequence of events is:

1. thread 1: grabs sandbox to process flow, flow processing begins
2. thread 2: sandbox is evicted
3. thread 2: listeners informed - fiber cache cleared
4. thread 1: flow processing ends, fiber added to fiber cache for a sandbox no longer in sandbox cache

This is not tested at all and there are no unit test changes etc. This PR is for initial feedback on the approach.

[sonarqubecloud]

Quality Gate passed

The SonarCloud Quality Gate passed, but some issues were introduced.

2 New issues
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[github-actions]

This PR is stale because it has been open 7 days with no activity. Remove the Stale label or add a comment - otherwise this will be closed in 7 days.

[github-actions]

This PR was closed because it has been stale for 7 days with no activity.