`Full` node handling is mostly untested

[sjakobi]

The problem is that to create a Full node, the hashes need to come in a very particular shape. For example, to create a Full root node, the hash data needs to cover all 32 (maxChildren) combinations for the lowest 5 (bitsPerSubkey) bits. I believe the current test input generators will very rarely produce such data if at all.

[sjakobi]

Ideally we can address this by completely removing the Full constructor (#399).

[sjakobi]

It might still be worth trying to modify the quickcheck generator for HashMaps to include some Full nodes at varying levels of the tree.

[sjakobi]

Some notable test coverage holes involving Full (in a test run with default settings):

D.HM.Internal:

• lookupCont
• insert
• insertNewKey
• insertKeyExists
• insertModifying
• unsafeInsertWithKey
• delete': when the deletion turns a Full node into a BitmapIndexed
• deleteKeyExists
• adjust#
• isSubmapOf:
  • Collision x Full
  • BitmapIndexed x Full
  • Full x Full
• unionArrayBy
• intersectionWithKey#
• filterMapAux

D.HM.I.Strict:

• insertWith
• unsafeInsertWithKey
• adjust
• unionWithKey

[treeowl]

I'm in the heart of the Jewish "holiday season", but once that's over I'd like to make another go of removing Full, if you haven't done it by then.

[sjakobi]

Some notable test coverage holes involving Full (in a test run with default settings):

[...]

FWIW, most of these holes can be filled (i.e. the corresponding branches can be executed and tested), by increasing QuickCheck's maxSize parameter, e.g. with cabal run tests -- --quickcheck-max-size=500. The default maxSize is 100.

(#519 prevents the testsuite from OOMing during such a test run.)