Reconsider ticket wait-time give-up: demote slow registrations instead of dropping, abandon only when replaceable by a shorter-wait candidate

[srene]

PR #62 drops a registration attempt when the ticket's cumulative WaitTime exceeds RegAttemptTimeout (1.5×AdLifetime), to avoid spending forever on a registrar that keeps returning long wait times.

Concern

A high-wait-time registrar may still be the only useful candidate for its bucket. Unconditionally giving up:

1. drains the bucket's candidate pool — the same failure mode p2p/discover/topicindex: renew registrations on expiry instead of dropping them #70 addresses for expiry, and
2. discards a registrar that would eventually admit us, with no guarantee a better one exists.

Proposal

Instead of dropping when WaitTime > threshold, demote the attempt to low priority (Standby) and abandon it only when there is a replacement candidate for the same bucket with a shorter wait time — opportunistic replacement, not unconditional give-up.

This mirrors #70's "demote-on-expiry instead of drop": prefer demotion over deletion; evict only when a strictly-better candidate is available.

Open questions

• How to compare wait times across candidates (a replacement may not have a TICKET response yet).
• Whether to keep the slow registrar's ticket warm in the background.
• Interaction with RegBucketStandbyLimit (standby pool cap).

Design/discussion issue.

[srene]

Precedent from the expiry path (#70)

The on-expiry handling in Registration.Update now uses an availability gate that's directly relevant here: when a Registered ad expires, the registrar is demoted back to Standby only if the bucket's standby pool has room; if standby is already full, the expired registrar is dropped instead, so a freshly discovered candidate can rotate in (retaining it would give no anti-drain benefit while blocking AddNodes from admitting new nodes).

case Registered:
    if att.bucket.count[Standby] >= r.cfg.RegBucketStandbyLimit {
        r.removeAttempt(att, "expired")   // pool full → drop, rotate fresh discovery in
    } else {
        // demote to Standby for renewal (avoid draining the candidate pool)
    }
    r.refillAttempts(att.bucket)

This partially answers the "interaction with RegBucketStandbyLimit" open question above: the wait-time give-up path can reuse the same count[Standby] >= RegBucketStandbyLimit gate to decide demote-vs-drop.

But note the distinction — availability vs latency

The expiry gate is purely availability-based (do we have spare candidates?). #73's core ask is latency-based (prefer a faster registrar even when we have room). Those are different criteria:

• The availability gate alone does not capture "replace a slow registrar with a shorter-wait standby candidate" — under it, a high-wait-time registrar sitting in a non-full pool is simply kept.
• So Reconsider ticket wait-time give-up: demote slow registrations instead of dropping, abandon only when replaceable by a shorter-wait candidate #73's "abandon only when replaceable by a shorter-wait candidate" is genuinely more than reusing the expiry gate, and that wait-time comparison (before a replacement even has a TICKET response) remains the hard part to design and the thing worth measuring on simnet.

Recommendation: layer the latency comparison on top of the availability gate rather than replacing it — i.e. demote-not-drop when there's room (consistent with #70), and additionally evict-and-replace when a same-bucket candidate has a demonstrably shorter wait.