[Rings] Wait for redelegation grace periods to elapse before updating rings

[bryanchriswhite]

Objective

While application re-delegation events may be observed within a session, which MUST update on-chain state, this SHOULD NOT effect the authority of the gateways until after the corresponding grace period has elapsed. This would become problematic during proof verification because 1) proofs are verified after the session (and some grace period) and 2) proof verification includes validating ring signatures, which therefore constrains the timing of re-delegation effectiveness (see: Redelegation Event Delays).

I.e. gateways which had authority to sign for an application which was delegated to it at the beginning of the current session should retain that authority until after the respective proof window has closed.

Origin Document

Redelegation Event Delays

Goals

• Ensure alignment of ring updates for on- & off-chain actors.
• Ensure proofs for sessions where the relay request was signed for by a delegate gateway are valid even when the respective application undelegates in that session.

Deliverables

• [x] A PR that updates the ring cache, the delegate and undelegate keepers to handle delayed undelegations, archival of old delegations and pruning of expired delegations.

Non-goals / Non-deliverables

• Have a more fine grained RingCache client.

General deliverables

• [ ] Comments: Add/update TODOs and comments alongside the source code so it is easier to follow.
• [ ] Testing: Add new tests (unit and/or E2E) to the test suite.
• [ ] Makefile: Add new targets to the Makefile to make the new functionality easier to use.
• [ ] Documentation: Update architectural or development READMEs; use mermaid diagrams where appropriate.

---

Creator: @bryanchriswhite Co-Owners: @red-0ne

[Olshansk]

Going to reword what @bryanchriswhite said from my POV just so it's clearer to me.

Assume the following:

1. App delegated to Gateway at start of Session (height=9)
2. Session started at height=10
3. Session will end at height=20
4. Gateway signed a relay on behalf of App at heigh=12
5. App undelegated from Gateway at height=15
6. Session ended
7. Claim & proof submitted
8. Proof is validated at some point after the session (e.g. height=26)
9. We need to know that Gateway was delegated to by App between height=[10,20) because the state of the blockchain at height=26 says otherwise

[red-0ne]

Close as per #518