Be more particular about limit argument to smartlist_split_string()
OSS-Fuzz claims that there's a ridiculously slow runtime for calling "diff-apply" when the line with the hashes has a whole bunch of fields in it.
That's because we call smartlist_split_string() with a final argument of "0", which means "no limit on the number of pieces to split this string into". That results in a whole bunch of allocations, which are slow under the AddressSanitizer that the fuzzer uses. I don't think this one is actually a great CPU DOS vector in the wild: malloc() isn't that slow when you aren't using asan.
But nonetheless we should go through all our calls to smartlist_split_string(), see which ones don't have a limit, and maybe impose a limit on them.
The Backport label on this ticket is tentative: we might want to backport important fixes we find here, if we think they might lead to problems down the line.