Fix IDLObjectSequence#calculateSizeBytes for variable-size elements

[PotatoPeeler3000]

Summary

IDLSequence#calculateSizeBytes's generic loop assumes elementSizeBytes() returns a size that is independent of the alignment context it was given, and separately computes+adds the leading alignment padding before each element via CDRBuffer.alignment(currentAlignment, elementSizeBytes). That holds for every fixed-size primitive sequence (e.g. IDLDoubleSequence, whose element size is always the constant 8, itself a valid CDR alignment boundary).

It does not hold for IDLObjectSequence: its elementSizeBytes() forwards to elements[i].calculateSizeBytes(currentAlignment), and a well-behaved CDRSerializable already bakes its own leading alignment padding into that call. Reusing the generic loop on top double-counts alignment, and does so incoherently, since CDRBuffer#alignment assumes its bytes argument is itself a valid power-of-two CDR boundary (1/2/4/8) - never true for an arbitrary struct's total encoded size.

Found while debugging why a two-element tf2_msgs.TFMessage.transforms sequence (geometry_msgs.TransformStamped[], each element containing a Header + string + Transform) computed a size tens of bytes off from what serialize() actually wrote. This matters because ROS2Publisher#writeAndPublish uses calculateSizeBytes() as the exact number of bytes to resize/copy to the outgoing DDS payload - any struct-sequence message (TFMessage, MarkerArray, DiagnosticArray, ...) published today over-copies whatever was previously in the write buffer as trailing garbage.

Changes

• IDLObjectSequence#calculateSizeBytes: override with a version that doesn't double-apply alignment, verified to exactly match what serialize() writes (see the new regression test).
• ROS2Publisher#writeAndPublish: defense in depth - use the buffer's actual post-serialize() position for the copied payload length instead of trusting calculateSizeBytes()'s estimate, so any future CDRSerializable whose two methods drift out of sync fails safe instead of shipping garbage/truncated bytes.
• Added IDLObjectSequenceVariableSizeElementTest: IDLObjectSequenceTest's TestIDLMsg fixture is a fixed 4 bytes per element (already a valid CDR alignment boundary), so it can't exercise this bug; the new fixture's size varies with a string field, matching the shape that triggered it.

Test plan

• ./gradlew :jros2-test:test - full suite: 763 tests, only the pre-existing AsyncROS2Test flake fails (reproduces identically on develop with these changes stashed out, so it's unrelated)
• New IDLObjectSequenceVariableSizeElementTest passes: calculateSizeBytes() now exactly matches serialize()'s actual output, and a deserialize round-trip is verified
• All existing IDLObjectSequenceTest, IDLDoubleSequenceTest, IDLIntSequenceTest, etc. tests still pass unchanged
• Real DDS ROS2PublisherTest suite still passes

[ds58]

Thanks,

I simplified the javadoc so it's a bit quicker to read