feat: Optimize proposal part handling logic in received_proposal_part

[varun-doshi]

Closes: #830

---

PR author checklist

For all contributors

• Reference GitHub issue
• Ensure PR title follows the conventional commits spec

For external contributors

• Maintainers of Malachite are allowed to push changes to the branch

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.77%. Comparing base (614a46c) to head (43fddab).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #837      +/-   ##
==========================================
- Coverage   75.79%   75.77%   -0.02%     
==========================================
  Files         169      169              
  Lines       14682    14682              
==========================================
- Hits        11128    11125       -3     
- Misses       3554     3557       +3     

Flag	Coverage Δ
integration	75.48% <ø> (-0.02%)	⬇️
mbt	20.63% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
core	∅ <ø> (∅)
engine	∅ <ø> (∅)
app	∅ <ø> (∅)
starknet	∅ <ø> (∅)

[romac]

Thanks for the PR! I need to think a bit more on it, because I am afraid that the solution I outlined in the PR and that you've implemented does not actually solve the problem, as it only filters out an outdated Init part but not any other part types.

I was thinking we could maybe use a bloom-filter of some kind to store stream ids of "outdated streams" (ie. stream ids for which we have seen an outdated Init part), but that does not work either in general because parts can arrive in any order and the Init part might arrive last. Therefore, an attack could still DoS a node by sending lots of outdated parts with the Init message at the end only.