Potential issue with slot data being obsolete when users remove relays from MEV-boost config.

[dvush]

The builder gets the fee recipient and suggested gas limit from the MEV-boost relay.
There are situations when this data can differ across different MEV-boost relays. To break ties between relays, we use relay priority (which is configurable) and select the slot registration with the highest priority (see relay_epoch_cache.rs).
Here's how this can play out and why the current tie-breaking policy can be problematic:

1. An MEV-boost user selects a set of relays and submits relay registrations to them, setting parameters to some value P0.
2. Later, they remove some relays from the list and change parameters to P1.
3. The relay that was removed from the set will still have the old parameters P0.
4. If this relay has higher priority, we will use stale parameters P0 to submit to all relays, but the relays actually used by the user will use P1.
5. When we submit to all relays, our blocks will either be rejected by the current relays that the user uses, or the user will get a block with parameters they no longer want to use.

To break this tie correctly in this situation, we need to use the most recent user registration (there is a timestamp attached to each registration).
It's also a good idea to verify the signatures of these registrations since they contain signatures.