better / more efficient realloc() fix from upstream umm

[d-a-v]

author's fixing branch with test: link

[d-a-v]

following discussion from #4134

Any particular case you're trying to fix/optimize, that can be tested against his changes? W/o a compelling reason, IMO it's a bit premature to pull in such fresh code in a bit of the core that's so important.

@earlephilhower You are right. Extensive tests must be done, and testing malloc (only realloc here) is not an easy task especially if there's improvement to see. The author included separate unit-test, we have umm internal integrity check, and one could setup a multi-strings manipulation sketch that would fill ram with some kind of success score to compare with the new proposed realloc.

[earlephilhower]

@d-a-v Actually, if the assumption is that "git head (from date XXXX to date YYYY) is unstable and may contain code that breaks your app, and should only be used to verify operation" maybe it's not so bad after all. We do some focused tests, somehow (maybe an app that's prone to breaking doesn't break for a series of tests), and then merge and let the larger community test.

It's not the friendliest of things, but "git head" is often unstable, no?

[d-a-v]

I believe head may also have experimental patch but I guess we are now on a freezing process for 2.4.1 fixing-release.
Anyway about UMM, I am going to use a malloc-hole-metric to check whether the new upstream realloc is better. Realloc is a lot used at least with String which are extensively used in sketchs, so it's worth the test.

[rhempel]

Thanks for using umm_malloc()! My test suite passed before the realloc() defect was reported - so obviously it was not a good enough suite. Memory manager bugs are notoriously hard to find, and I appreciate that your team is sticking with umm_malloc().

Please keep me up to date on progress, and once the (issue-11) branch is verified, I will merge back to (master) and bump the release version so that everyone gets the latest and greatest.

[earlephilhower]

Seems like a good thing to pull in. Seems to have just gotten lost in the 2.4.1 crunch.

[d-a-v]

#6438 will handle this