JAMES-4172 Fix truncated downloads for non-SingleBody EmailBodyPart b…

[omerfarukicen]

https://issues.apache.org/jira/browse/JAMES-4172

In EmailBodyPartBlob, the size and content methods used different calculation paths for non-SingleBody parts (e.g. message/rfc822):

• size relied on SizeUtils.sizeOf(entity) which returns the decoded size via SingleBody.size()
• content used DefaultMessageWriter.writeBody() which re-encodes the content (e.g. base64), producing more bytes than the decoded size

This mismatch caused Content-Length to be set smaller than the actual response body, resulting in truncated .eml downloads with missing attachments and MIME boundaries.

Fix by caching the written body bytes in a lazy val so that both size and content use the same data, ensuring Content-Length matches the actual stream length.

[quantranhong1999]

https://ci-builds.apache.org/job/james/job/ApacheJames/job/PR-2940/1/testReport/org.apache.james.jmap.rfc8621.memory/MemoryEmailParseMethodTest/parseShouldSuccessWhenAttachment_GuiceJamesServer_/

Related?

[chibenwa]

No strong objections

Let's fix the build and merge this.

[omerfarukicen]

The test parseShouldSuccessWhenAttachment fails because the size value changed from 797 to 807.

This is expected: the old code used SizeUtils.sizeOf(entity) which computes size via SingleBody.size() (decoded size), while the new code uses the actual byte count from DefaultMessageWriter.writeBody() (the real serialized size). The 10-byte difference comes from this discrepancy.

Since 807 reflects the true size of the written blob content (consistent with Content-Length and the actual download stream), I believe the test expectation should be updated to 807.

Shall I update the test to expect 807 instead of 797?

[chibenwa]

Shall I update the test to expect 807 instead of 797?

Likely yes!