LDEV-6447 Correct sessionInvalidate() lifecycle

[shane-tw]

Summary

sessionInvalidate() used create-if-missing HttpServletRequest.getSession() calls while invalidating and resetting a JEE session. Tomcat rejects session creation after the response is committed:

Cannot create a session after the response has been committed

It also eagerly created a replacement session before commit. A client could reuse that replacement JSESSIONID, even when the caller intended the session to be completely destroyed.

This change:

• uses getSession(false) throughout invalidation so it never creates a servlet session merely to destroy it;
• invalidates the existing JEE session after a committed response without creating a replacement;
• stops eagerly creating replacement CFML and JEE sessions during sessionInvalidate();
• lazily creates a clean session if CFML subsequently accesses SESSION; and
• preserves sessionRotate() ID rotation and data migration.

The LDEV-4166 regression now verifies the actual contract: onSessionEnd runs synchronously for the invalidated session and no replacement session remains. Its previous session-count assertion accidentally encoded eager replacement behavior.

Validation

• Added a servlet regression proving the original JEE session is invalidated, no replacement exists immediately afterward, and later SESSION access creates a clean session with a new ID.
• Added servlet regressions for invalidation after commit with both an existing session and no existing session.
• Confirmed the updated LDEV-4166 assertions fail on the previous implementation for both CFML and JEE sessions.
• Focused Maven session suite passes: SessionInvalidate, LDEV-4166, and the LDEV-6046 memory case (4 tests passed; database and servlet-only cases skipped where their services were unavailable).
• Java 11-targeted core and loader builds complete successfully.

Ticket: LDEV-6447