Trying to get a new [sub]bundle when there are too many triggers an assertion failure

[ajhconway]

This should be handled better.

[ajhconway]

Also branches

[gapisback]

While triaging and trying to reproduce other open issues, discovered that the following test execution off of /main (at SHA bcd7933) reports one of the types of assertions reported here-in; i.e. running out of bundles:

$ build/release/bin/driver_test splinter_test --perf --num-insert-threads 4 --tree-size-gib 2 --num-memtable-bg-threads 2 --num-normal-bg-threads 2
build/release/bin/driver_test: splinterdb_build_version bcd7933f
Dispatch test splinter_test
[...]

splinter_perf_inserts() starting num_insert_threads=4, num_threads=20, num_inserts=27185152 (~27 million) ...
Thread 2 inserting  57% complete for table 0 ... OS-pid=3493221, OS-tid=3493223, Thread-ID=2, Assertion failed at src/trunk.c:1969:trunk_get_new_bundle(): "(node->hdr->end_bundle != node->hdr->start_bundle)". No available bundles in trunk node. page disk_addr=393216, end_bundle=4, start_bundle=4

Possible solution (straw-man) Would be to change the assertion in trunk_get_new_bundle() to instead raise an error message and then to return an invalid bundle-number (say, TRUNK_MAX_BUNDLES).

All callers to this function would then have to check this returned value and do some proper error handling, or early exit.

Similarly, change the assertion in trunk_get_new_subbundle() to raise an error and then return NULL from this function for trunk_subbundle * ptr.

Unfortunately, many of the functions where this trunk_get_new_bundle() or trunk_get_new_subbundle() is called are currently not equipped for proper error reporting / error handling.

Need to think this through w/help of @ajhconway to figure out if there are some larger re-work / re-designs that could improve the error handling in this area.