fix(admin): reject JWTs issued before a password change or revocation - #8235

Fixes #8176

Problem

The Admin realm verifies the JWT signature/expiry and the current account status, but never compares token state with the account's credentials. modifyPassword updates the password hash without revoking tokens issued with the old password, so an old token stays accepted for up to its 24h lifetime — on every Admin instance.

Modifications

A per-user token version is now persisted and carried in the JWT:

• dashboard_user.token_version in the MySQL/PostgreSQL/Oracle/H2 init scripts and in the 2.7.2→2.7.3 upgrade scripts (MySQL, PG, Oracle, H2, OceanBase, openGauss). New accounts start at 0.
• JwtUtils writes the tokenVersion claim on login and reads it back; tokens without the claim are reported as LEGACY_TOKEN_VERSION (0).
• ShiroRealm rejects a token whose version differs from the stored one, after signature and expiry verification.
• A self-service password change, an administrative password reset and an explicit revoke increment the version in SQL (token_version = token_version + 1, DashboardUserMapper#incrementTokenVersion). Concurrent changes cannot overwrite each other with a stale read-modify-write value, and the credential write and the increment share one transaction.
• PUT /dashboardUser/revoke/{id} (system:manager:edit, root admin) revokes every token of an account without changing its credential. It re-reads the stored row before publishing the audit event, and UserChangedEvent now reports the version change.
• The full insert/update mapper statements intentionally omit the column (documented in the XML): a new row takes the default 0, and a full update must not reset revocation state.

Because the version lives in the database, revocation applies on every Admin instance and does not rotate the shared signing key. Other users' tokens are untouched, and the existing account-disabled rejection is unchanged and still runs before the version check.

Compatibility / rolling upgrade

• Tokens issued before this change have no tokenVersion claim and are treated as version 0, so existing sessions survive the upgrade and keep working while the account's version is 0.
• After the first password change or revoke the account moves to version 1; legacy tokens and tokens minted by a not-yet-upgraded Admin instance (which cannot write the claim) are then rejected.
• Operational rule: complete the upgrade before performing password resets or revocations. An old Admin instance cannot increment the version, so a reset it handles leaves the column at 0 and pre-reset version-0 tokens remain valid. Old instances also do not check the version, so a revoked token is accepted by them until they are upgraded. No per-user key rotation is involved.

Verifying this change

• JwtUtilsTest 27/27 — claim round-trip and a legacy (no-claim) token reported as version 0.
• ShiroRealmTest 6/6 — matching version accepted; bumped version rejected; legacy token accepted at 0 and rejected after the account moves to 1; testPasswordChangeInvalidatesOldTokenAndAcceptsFreshLogin covers the acceptance path end to end.
• DashboardUserServiceTest 13/13 — password change and admin reset bump the version through the atomic statement; revokeTokens never writes an absolute version and publishes the stored row; non-admin revoke is rejected.
• DashboardUserControllerTest 10/10 — new endpoint wiring.
• DashboardUserMapperTest#testIncrementTokenVersion and #testConcurrentIncrementsAreAtomic (8 threads × 5 increments) prove the SQL-side increment loses no updates.
• ./mvnw -pl shenyu-admin validate — checkstyle green.
• Master's own test compile is broken (InstanceCheckService gained an InstanceRetentionProperties constructor argument in [ISSUE #7717] Add opt-in retention cleanup for expired instance records #7971 without a fixture update), so this branch carries the same fixture change as test(admin): adapt long-polling fixtures to instance retention #8247 (22b3896d4) to unblock CI; it merges cleanly once test(admin): adapt long-polling fixtures to instance retention #8247 lands.

Make sure that:

• You have read the contribution guidelines.
• You submit test cases (unit or integration tests) that back your changes.
• Your local test passed ./mvnw clean install -Dmaven.javadoc.skip=true — the module's targeted tests and checkstyle were run; the full install was not run in this environment.