Spam filter logic only acts on different rounds, not heights or invalid messages

[OnedgeLee]

AS-IS

• If some peers send ConsensusMessage for different round too often, recipient will add those peers to deny list, and will deny messages from that peer till new height has been started.
• This logic prevents VoteSet from keeping too many messages.
• But there are no protection logics for different height ConsensusMessages. (This will affect both of Gossip memory and VoteSet)
• Also, there are no protection logics for invalid ConsensusMessages. (This will affect Gossip memory)
• We can assume those spam filter logic is up to network or transport layer, and do nothing. (Assume Libplanet is not responsible)
• But I think it's beneficial for Libplanet to have protection logics on the view of product, if we can do something for that.

TO-BE

• Spam filter logic to cover different height messages, and invalid messages

Want to discuss

• Do or not

Related issue

• Implement spam filter logic on GossipConsensusMessageCommunicator #3266