Move ChecksumHandle and its methods into their own module

[wenkokke]

This PR:

• Moves ChecksumHandle and its core functions to their own module (Database.LSMTree.Internal.ChecksumHandle).
• Generalises the helper functions in RunBuilder (writeRawPage, writeRawOverflowPages, writeBlob, copyBlob, writeFilter, writeIndexHeader, writeIndexChunk, writeIndexFinal) to only take the arguments they need, rather than the entire RunBuilder.
• Moves those helper functions to the new ChecksumHandle module. This enables them to be reused by the WriteBufferWriter. (Technically, the latter four are not needed, but it seemed better to generalise and move them for consistency.)

[jorisdral]

Looks good in general! I have some suggestions

[jorisdral]

Suggested change

	{- | $checksum-handles
	A handle ('ChecksumHandle') that maintains a running CRC32 checksum.
	-}
	{- $checksum-handles
	A handle ('ChecksumHandle') that maintains a running CRC32 checksum.
	-}

[wenkokke]

I'm merely following the syntax of the block right above this one, so I think either zero or two changes are warranted.

[jorisdral]

Which block do you mean?

[wenkokke]

This one:

lsm-tree/src/Database/LSMTree/Internal/CRC32C.hs

Lines 241 to 244 in d0ae185

	{- | $checksum-files
	We use @.checksum@ files to help verify the integrity of on disk snapshots.
	Each .checksum file lists the CRC-32C (Castagnoli) of other files. For further
	details see @doc/format-directory.md@.

[wenkokke]

Which does indeed render weird:

[jorisdral]

Where functions like writeRawPage would previously select the correct handle from the RunBuilder such as forRunKOps runBuilderHandles, the new newRawPage could in theory be passed any ChecksumHandle. It's probably not a problem in practice, as the tests would catch incorrect usage. Still, if you think it's a good idea we could introduce some type safety by adding some newtypes, such as newtype KOpsHandle s h = KOpsHandle (ChecksumHandle s h)

Thinking along those same lines, writeBlob and copyBlob are currently passed a variable holding the offset into the file: this could also be a bogus variable with no connection to the blob file. Maybe for the blob handle, we can introduce data BlobHandle s h = BlobHandle !(PrimVar s Word64) !(ChecksumHandle s h) instead of a newtype around just the ChecksumHandle part

[wenkokke]

That might be useful. I took them out of the wrapper because otherwise I'd need additional handles for two nonexistent files. Wrapping them up individually would indeed solve that. Would you like me to implement that?

[jorisdral]

You can implement it, or leave a TODO, what you prefer

[jorisdral]

BTW, the suggestion to change FS.Handle h to h and PrimState IO to RealWorld should be applied to all specialisations, not only the ones I put a comment on

[jorisdral]

LGTM. Let's squash the first 3 commits together, and the last 2 commits together