Control Transaction Summary date in beacon chain

### Describe the problem you discovered

Actually there is a control in the Subset to ensure a replication attestation is within the expected interval of time of the current summary (current or previous summary).
But this control is not done when a beacon summary node receive a slot, or when a node is using a beacon summary aggregate in the self repair.
So a malicious node could add an "old" transaction inside a slot and send it to a summary node. Then a summary and summary aggregate will be created with this old transaction leading to an error or a replication of a malicious transaction

### Describe the solution you'd like

When a summary node receive a slot (`NewBeaconSlot` message) it should ensure all the transaction are within the expected time (actually only confirmations are checked). And when a node use a summary aggregate during the self repair, it should reject the non expected transaction.

Start by tracing the NewBeaconSlot handling and the self-repair path that consumes a beacon summary aggregate. Compare both paths with the existing Subset replication-attestation interval check; done means transactions outside the expected current or previous summary interval are rejected in both cases.

Written by the indexing model from the issue text.