p2p: fix data corruption on longer packets

[mzabaluev]

The code handling chunking of data frames longer than the configured
maximum was faulty.

May fix #1392 and possibly other occurrences of data corruption.

• Referenced an issue explaining the need for the change
• Updated all relevant documentation in docs
• Updated all code comments where relevant
• Wrote tests
• Added entry in .changelog/

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (62ddb98) 58.6% compared to head (4777142) 60.2%.

❗ Current head 4777142 differs from pull request most recent head a9486b3. Consider uploading reports for the commit a9486b3 to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #1393     +/-   ##
=======================================
+ Coverage   58.6%   60.2%   +1.5%     
=======================================
  Files        273     270      -3     
  Lines      27936   26080   -1856     
=======================================
- Hits       16397   15709    -688     
+ Misses     11539   10371   -1168     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tony-iqlusion]

Worth a shot at least, although I think ideally the buffer management would be changed so this library allocates the buffer and DATA_MAX_SIZE is just a sanity limit

[mzabaluev]

ideally the buffer management would be changed so this library allocates the buffer and DATA_MAX_SIZE is just a sanity limit

The protocol always sends full AEAD frames, and long messages are split between successive frames, with the last frame padded. So, regardless of what the doc comment says, DATA_MAX_SIZE only defines the size of the encrypted frames. In plaintext, the message is length-prefixed.