Proto: relax slot constraint in mempool mode

Context

Main change and motivation

This MR makes the validation in mempool mode no longer check whether the slot of a (pre)endorsement is the smallest of the delegate's slots when the operation points to the head level. This makes the mempool mode more consistent, because it already didn't check this property for older or newer levels. This also means that we no longer need to compute the endorsement rights by first slot at the head level, which makes the initialization of a mempool around 5ms faster.

MR flow

• In validate.ml, remove the special case for the head level, where the validation used the pre-computed rights table by first slot, and therefore rejected operations whose slots weren't minimal.
• No longer compute the rights table by first slot in mempool mode. (This part is split into several commits.)
• No longer compute the rights table by first slot for preendorsement in application mode when we know that there cannot be any preendorsements in the block. (This is not part of the main goal of the MR, but it is a similar optimization made possible by the previous refactoring.)
• Make the Wrong_slot_used_for_consensus_operation permanent again, now that the mempool mode never returns it, instead of potentially raising it for operations that were previously classified as valid on a different head. This fixes #5061 (closed).
• Make it possible to denounce double (pre)endorsements with distinct slots belonging to the same delegate. Indeed, it would otherwise be possible to spam mempools with valid operations with various slots. Note that the accuser will need to be patched to be able to issue such denunciations (#5094).

This MR depends on !7815 (merged).

Follow-up issues: #5093 and #5094.

Manually testing the MR

CI

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• [N/A] Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR