Improve entry crc32 computation
We have a codepath difference here, where we use either a ByteBuffer or
a raw array to compute CRC32.
MappedJournalSegmentWriter does not make it immediately clear we use
this buffer twice -- once for CRC32 and once for deserialization.
Move acquisition of slice just after we have read the expected CRC32, so
it is clear it is something we would be doing even if there were no
checksum involved.
Mirror the same in FileChannelJournalSegmentWriter, as this will allow
us to further consolidate the code and stop mucking with memory.limit(),
which is causing us to invalidate our previously-set mark.
JIRA: CONTROLLER-2095
Change-Id: I355bd97cd8acb4f5d9d91310de97ecb2cbd70282
Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
(cherry picked from commit
b8dfbae75d8e13b78d3a7d5db48de2f5e262cd87)