Related to WFLY-12815.

In a scenario where session timeouts (meaning we use HttpSessionDestructionContext) and there are lifecycle listeners for session destruction that throw an exception, your listener won't get called and the context will stay active on that thread. This means that any subsequent usage of this thread for session will blow up with multiple active contexts for given scope.

What we can do is to check, on session context activation, for any leftover destruction context and clear that up plus do some logging. In theory this should be safe as I cannot imagine a situation where a leftover active destruction context would be intentional. It won't be perfect solution, but it is more robust than what we have now.

An automated test is probably not viable as we would need to "corrupt" all thread in WFLY to be able to reliably achieve the faulty state. Hence I will put together a PR, test that against our TS, then WFLY TS and ask the original reported to verify as well.