[ISSUE #8039] Add the opt-in server-issued registration lease - #8363

Part of #8038. Resolves #8039.

Problem

The /instance/beat endpoint proves instance liveness by timestamping the last received beat, but nothing about that liveness is explicit: the endpoint answers with a bare success marker, the offline and deletion thresholds are hard-coded constants inside the liveness check, no lease identity ties a beat to a negotiated agreement, and nothing tells the client when the instance will be considered gone or at which cadence it should renew. The registration fencing contract (boot-session-fencing-v1) explicitly leaves automatic lease expiry out of its scope, and the acceptance criteria of this issue call for lease identity, a negotiated heartbeat interval, server-side receipt time, an expiry deadline, idempotent renewal and pinned scenarios for duplicate, delayed and lost beats, clock skew, restart and final removal.

Approach

This introduces the opt-in registration-lease-v1 capability on the existing beat endpoint. When shenyu.register.lease.enabled is false, no capability is advertised and every legacy byte of the v1 behavior is unchanged: the response stays the plain success marker, the thresholds stay the hard-coded constants, and the payload fields the client now may send are ignored by old Admins like any unknown JSON field.

When enabled, the Admin advertises registration-lease-v1 next to the existing capabilities and answers a capability-presenting beat with a structured document: {code, leaseId, intervalSeconds, expiryDeadlineMs, message}. The server decides the interval — clamping any client proposal into the configured bounds — and the deadline is receipt + expiryFactor * interval. Renewals are idempotent: the new deadline is the maximum of the previous deadline and the freshly computed one, so duplicate, delayed or replayed beats can never push the deadline past the last server receipt. A beat presenting an unknown lease id is rejected with STALE_LEASE; renewing an already expired lease answers EXPIRED; both are terminal for the presented lease and never refresh the liveness timestamp, so a client that lost its lease cannot keep its instance alive without re-registering. A re-registration beat with a blank lease id attaches to the current lease of that instance without resetting its deadline, and once the lease has expired it grants a fresh one — the only path that recovers an expired instance. Fenced business addresses (boot-session-fencing-v1) stay out of lease scope and keep their short-circuit; external registries keep owning membership and expiry for their own registrations.

The Java reporter keeps its fixed 5-second scheduler and gates each Admin by the server-issued interval — the smallest negotiable interval (2s) with a three-interval deadline can never be missed by the tick granularity. A renewal is compact: identity plus lease id, with the full instance observation attached only on (re-)registration and once every 12 consecutive renewals. Transport failures defer the next attempt by the current interval plus bounded jitter; there is no failback loop. Client-side the feature is separately opt-in (registrationLease=true), so an upgraded client changes its wire behavior only when operators turn it on, and a mixed Admin cluster negotiates independently per server url. The lease state lives in the memory of the Admin that owns the liveness checks (the cluster master, which receives forwarded beats and rebuilds from the database on failover); an Admin restart invalidates outstanding leases and clients recover through the re-registration path, which is documented together with the fenced-owner release follow-up in the new REGISTRATION_LEASE.md.

Testing

All timing-dependent scenarios run against a controlled clock or injected nanotime supplier — no test sleeps. The server tests cover grant and renewal with exact deadline arithmetic, monotonic deadlines under delayed or replayed renewals, idempotent duplicates, stale and expired rejections that leave the deadline untouched, re-registration recovery, proposal clamping, offline exactly at the lease deadline (and not before), compact renewals preserving the last observation, the fenced short-circuit, the exact legacy response without the capability header, and the capability advertisement. The client tests cover the legacy wire remaining byte-identical when the feature is off, the capability header and lease payload when on, honoring the server-issued interval, compact renewals, re-registration after EXPIRED, the legacy cadence for a server answering the v1 marker, and bounded deferral after transport failures.

shenyu-register-protocol 2 tests, shenyu-register-client-beat 36 tests (31 existing + 5 new), shenyu-admin 2735 tests (2718 existing + 21 new; the single ShenyuClusterServiceTest failure is the pre-existing flaky, green 9/9 when re-run alone), Checkstyle clean on all four touched modules.