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.

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

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

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

:exclamation: 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

```diff @@ 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 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[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.