Fish 8174 improve thread expire validation to read lastaccesstime

[breakponchito]

Adding fix to guarantee each thread update lastaccesstime and thisAccessedTime after validating if session hasExpired.

Description

This is a fix for a reported bug regarding http session management when using cluster configuration with lite and normal Payara micro instances.

Important Info

Blockers

Testing

New tests

Testing Performed

Manual testing with reproducers included on the ticket:
https://payara.atlassian.net/browse/FISH-8174
not only can be tested with docker configuration but also with local environment with stand alone Payara Micro. Here the steps:
Use following war file, and configuration files on the following zip:
Reproducer.zip

unzip on the place where the payara micro jar is installed:

the application on the war file set the session timeout limit to 1 minute, if you need to configure more time use the following zip file with the code and customize the time as you need:
Shared-Session-Code.zip

then create two instances of Payara Micro with the following commands:
instance1:
java -jar payara-micro.jar --clustermode multicast --clusterName myService-cluster --deploy Shared-Session-1.0.war --nohostaware --logProperties logging.properties --hzConfigFile payara-hazelcast.xml

instance2:
java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=9002 -jar payara-micro.jar --lite --clustermode multicast --clusterName myService-cluster --deploy Shared-Session-1.0.war --nohostaware --logProperties logging.properties --hzConfigFile payara-hazelcast.xml --port 8081

open browser with two tabs for the following URLs:
open first and with a chronometer, from the mobile calculate 1 minute
http://localhost:8080/Shared-Session-1.0/safe
this is going to create the session

then open second with the other url:
before to achieve the timeout (60 seconds), for example second 57 or 58
http://localhost:8081/Shared-Session-1.0/safe

then you will see that the session is not recreated, just the values for the lastaccesstime and the thisAccessedTime are updated this will fix the problem of the gap for the session. From the reported issue the session is expired and created a new one 2 or 3 seconds before the timeout

for 2 minutes:

I tested the following configuration of timeouts:

1 minute
2 minutes

then I tested with 3 instances, trying to call each instance 2 or 3 seconds before timeout

and last with 4 instances, trying to call each instance 2 or 4 seconds before timeout

Testing Environment

Windows 11, Azul JDK 11, Maven 3.9.5, Payara 6
Ubuntu 20.04, jdk 11, Maven 3.8.6, Payara 6

Documentation

Notes for Reviewers

[breakponchito]

Jenkins test please

[Pandrex247]

A number of files need their copyright updating, and as you've mentioned yourself the logging needs cleaning up (at the very least setting the log level to finest!), and I don't have time to properly test it right now, but the overall concept LGTM.

[breakponchito]

Jenkins test please

[breakponchito]

Jenkins test please

[breakponchito]

Jenkins test please

[breakponchito]

Jenkins test please

[breakponchito]

Jenkins test please

[breakponchito]

Jenkins test please

[breakponchito]

Jenkins test please

[breakponchito]

Jenkins test please

[breakponchito]

Jenkins test please

[breakponchito]

Jenkins test please

[luiseufrasio]

LGTM!

[breakponchito]

Jenkins test please

[breakponchito]

Jenkins test please

[lprimak]

Unfortunately this PR introduced a regression.
As you can see below, there are dangling BackgroundSessionProcessor threads.
In other words, more BackgroundSessionProcessor threads than the BackgroundProcessor threads after an webapp is undeployed.

[lprimak]

Another regression introduced by this PR found. Stay tuned, I submitted another PR