Validating created and expires of timestamps fails when DST changes while application is running

## Problem / actual behavior
To verify the values of "created" and "expires" of a ws-security timestamp, the offset of the applications current timezone to UTC is calculated. Unfortunately, this happens in a static initialize block of the class [`DefaultSecurityEnvironmentImpl`](https://github.com/eclipse-ee4j/metro-wsit/blob/2.4.7/wsit/ws-sx/wssx-impl/src/main/java/com/sun/xml/wss/impl/misc/DefaultSecurityEnvironmentImpl.java#L92). If the daylight saving time changes while the application is running, which is a quite common use-case for a web-service, this previous computed offset is still used afterwards.

### Example
An example: the timezone is Europe/Berlin with DST on (means CEST aka GMT+2). The computed offset will be two hours. Let it be now 31/10/2021 at 3 am. The time changes to 2 am as DST got switched of and we are now back in "normal" time CET/GMT+1 with an offset of one hour. Incoming requests with a valid timestamp will be rejected from now on with error "The creation time is ahead of the current time.".

The adjusted current date uses the right local time (2 am) but the old offset of two hours is subtracted. A timestamp with a "created" value of 1 am UTC will then be treated as a future timestamp because `DefaultSecurityEnvironmentImpl` "thinks" the current time is midnight.

Similar when DST will be switched on but the error will then be "The creation time is older than currenttime - timestamp-freshness-limit - max-clock-skew".

## expected behavior
The offset must not be initialized statically! It should be computed on each invocation of [`DefaultSecurityEnvironmentImpl#defaultValidateCreationTime`](https://github.com/eclipse-ee4j/metro-wsit/blob/2.4.7/wsit/ws-sx/wssx-impl/src/main/java/com/sun/xml/wss/impl/misc/DefaultSecurityEnvironmentImpl.java#L1184). The affected methods `getFreshnessAndSkewAdjustedDate` and `getGMTDateWithSkewAdjusted` do already contain code to do so but it is commented out.

## Possible workarounds
- scheduled reboots after DST changes
- implement an own handler for a `TimestampValidationCallback`

Start with wsit/ws-sx/wssx-impl/src/main/java/com/sun/xml/wss/impl/misc/DefaultSecurityEnvironmentImpl.java, especially defaultValidateCreationTime and the commented offset logic in getFreshnessAndSkewAdjustedDate and getGMTDateWithSkewAdjusted. Confirm how the static offset is used, then verify that timestamp validation recalculates the timezone offset after a DST change.

Written by the indexing model from the issue text.