Missing flood protection check for number of message IDs when handling Ihave messages

[cortze]

Description

After looking at the gossipsub Iwant/Ihave handlers, I realised that there is a missing spam prevention check when opening the Ihave messages from a received ControlMessage.

To give some context, the spec defines that each Ihave message should have an upper limit of aggregated message IDs, which in this go implementation is defined by maxMessageLength = 5_000 message IDs per Ihave and topic, as Ihave messages can be aggregated in a single RPC call.

This spam check is already done at the moment of emitting the Gossips. However, I can't see a similar check at the moment of handling each of the message IDs within the Ihave messages.

We do checked that the remote peer stayed within the number of Ihave messages, and that we didn't exceed the message ID count for asked messages, but it doesn't check anything related to the size of the array of message IDs per each topic I have.

This PR adds that missing spam protection step, ensuring that we only read the first maxMessageLength messages of each Ihave as @MarcoPolo suggested.

Let me know if there is anything else that should be added or modified.

[vyzo]

fair enough.