fix(protocol): don't terminate retrieval threads on messages with trailing bytes (DoS)

[damip]

Summary

The block and operation retrieval workers each run a single long-lived select! loop
that serves all peers. When a network message deserialized successfully but left
trailing bytes (!rest.is_empty()), both loops did:

if !rest.is_empty() {
    println!("Error: message not fully consumed");
    return; // <-- terminates the whole shared retrieval thread
}

A return here kills the entire retrieval thread, so a single peer sending a valid
message prefix followed by junk bytes can permanently stop block/operation protocol
handling for every peer — a denial-of-service. The stray println! also bypasses the
logging framework.

Change

In both block_handler::retrieval and operation_handler::retrieval, treat a message
with trailing bytes as a per-message error: log a warn! (including the offending peer
and the number of trailing bytes) and continue the loop instead of returning. The
worker keeps serving other peers.

Testing

• cargo build / cargo clippy clean for massa_protocol_worker.
• The fix is a control-flow change (return → continue) inside the workers' large
  select! loops; a faithful regression test would require standing up the full
  retrieval worker with network/pool/mock wiring, so no bespoke unit test is added.
  The change is small and self-contained.

Risk

Low — well-behaved peers never send trailing bytes, so the only behavioural change is
that a malformed/hostile message no longer tears down the shared worker. We
intentionally keep the change minimal (log + skip) and do not add peer-banning here;
banning on trailing bytes can be considered as a follow-up.

Tracking: findings F120 and F128.

[Leo-Besancon]

LGTM, indeed peer banning as follow-up seems like a good idea.
Is there an issue regarding this?