optimize createFpAndTrim with shrinkMutableByteArray#

[oberblastmeister]

Addresses #549

[clyring]

It looks like GHC indeed behaves poorly when shrinking large MutableByteArray#s. I've created GHC issue 22994 to track that upstream.

[clyring]

Personally I would rather not depend on the implementation details of base that mean we always get PlainPtr here, even though the alternative is touching the MutableByteArray# primitives ourselves locally.

Thoughts? @Bodigrim @sjakobi

[Bodigrim]

I'd write shrinkFp _ _ = pure () instead of error, but otherwise looks sane to me as is.

[clyring]

This condition is the main tricky bit.

• Large MutableByteArray#s do not return their memory to the RTS when we shrink them in-place. But they do return their memory to the RTS when we make a copy.
• Small pinned MutableByteArray#s may well retain all of their memory regardless of whether we shrink in place or create a copy, because of how they are currently allocated in GHC. (There are probably several GHC issues related to this topic. See for example this one and this one. It's not clear if or when this will be improved.)

So we want to make a copy when:

• We expect the underlying buffer to be a large heap object, and
• the amount of space shrinking would leak is large enough to care about.

If I recall correctly, the exact threshold for when a buffer is allocated as a large heap object depends on both the platform and the GHC version, but has been somewhere around 3K for 64-bit systems and half that for 32-bit systems for some time now.

(This reasoning should be documented in the code.)

[Bodigrim]

@oberblastmeister could you please rebase?