Investigate how de-coupling JCR workspace ID from user context may allow concurrent model operations to leverage the request-scoped JCR session handler

[ghost]

There is a residual usage in the code base post-#2265 refactory still associating a "tenant ID" (aka a JCR workspace ID for ModeShape) with a IUserContext instance.

There is no logical reason to keep that kind of association since JCR workspace IDs are primarily associated with Vorto namespaces by design (this is not a new concept either).

There is strong suspicion that this may be the root cause of our inability to leverage the RequestRepositorySessionHelper bean when performing back-end repository operations concurrently.

This, in turn, implies that any optimization leveraging concurrency has its drawbacks insofar as it doesn't efficiently reuse ModeShape sessions within request scope at this time.

Regardless of whether the correlation between the workspace ID and user context association and the inability to leverage the RequestRepositorySessionHelper in a concurrent context is well founded, that specific association can and should be sanitized either way.