Priority-based relayer coordination protocol: required modifications

[svyatonik]

Filing this issue to track remaining work that needs to be done after #2605 is merged:

• relayer can deregister from lane without any penalty only after it has delivered at least one message (so we assume it'll be working for at least one epoch). Another option to deregister is to be pushed out by relayer with better bid (lower expected reward). See Finishing "Additional priority boost for relayers that have explicitly registered at lane" #2605 (comment) for details;
• randomly select block that ends relayers "auction". For BH - use randomness coming from relay chain. See Finishing "Additional priority boost for relayers that have explicitly registered at lane" #2605 (comment) for details;
• to avoid contention during single auction, maybe we need to limit number of times when relayer is able to change his bid - e.g. to 1 time per auction (or use some alternate solution). This is only possible if we'll implement previous point, though. If we won't do that, and if there's a lot of relayers, figting for the slot, we may end up with many unneeded transactions where relayers are registering using a slightly better price (worst - 1);
• right now relayer can't claim his reserved lane stake back (if he has deregistered at lane or has been pushed out of the queue) easily. It can call register again and prolong his basic registration or it can wait till the registration end and call deregister to claim all reserved funds. Let's maybe add a separate call to release funds? UPD: maybe we could add two calls - one to reserve more funds and another to release blocked funds. Other calls shall only check that the reserve is enough to cover basic + lane registrations? It should make everything easier The code for managing stake was too complex, so I've changed it right in Finishing "Additional priority boost for relayers that have explicitly registered at lane" #2605. See 1f04623 for details;
• the advance_lane_epoch is free when it succeeds. But it is callable by anyone. We can add another "obsolete" extension that would reject advance_lane_epoch when epoch is already advanced (recently?);
• think of partially rewarding the lane relayer even if messages were delivered by some other relayer during his slot;
• current weight formulae for new calls are assuming worst possible conditions. We may change calls to return actual post-dispatch weight.