BUG: Overflow in find_best_slab if more than half of a slab that is being split is dirty #2

Fixed in: 22198e0

If an untyped slab (passed from the rootserver) is dirty beyond half of its size (atm this is only the case for system CAmkES components, if they grow in size beyond half of a slab from which they are allocated), find_best_slab would cause an overflow here:

(nfo.remainingBytes will be smaller than half of the slab size (since its dirty beyond halfway point), and l2tob(size_bits) in the current use of the function is always exactly half the size of the slab, so would cause an overflow (larger number subtracted from a smaller one). This results in optimal "best_bits" to being found by this function if the overflow happens, even if it is impossible to allocate such a big object and results in a failed Untyped_Retype invocation:

 Untyped Retype: Insufficient memory (1 * 131072 bytes needed, 0 bytes available)

Longer log available: https://pastebin.com/0NSpAj46 (stopped early due to infinite loop while trying to split)

(Note: needs to be verified, will do that ASAP)
Verified :

• Original main branch of Open Se Cura, commit: https://opensecura.googlesource.com/sw/cantrip/userland/+/2a11c2a84616aafe3045a139f8762002190e8073 ; triggered e.g. when setting heap size in DebugConsole >90 * 1024 B (Exceeding halft the size of slab on which system components reside; production build)
• My branch of CantripOS and modified kernel (with O(k) modification) just before commit: 22198e0 ; triggered e.g. when setting heap size in DebugConsole >27 *1024 B (exceeding half the size of slab on which system components reside; production build)

Verified fix on my branch, both when occupying <1/2 the slab, and >1/2 of the slab for 4 different sizes, the newly created slabs fully utilise the remaining space, and do not cause the system to loop/panic.

TODO: Awaiting verification from Sam Leffler and confirmation whether fix in 22198e0 is acceptable.