Fixes oss-fuzz case 394129398.
Issue arose from chaining multiple runlength filters and inflating a
compressed stream of ~100 bytes to several gigabytes.
There is no obvious fix without imposing an arbitrary implementation limit
and therefore potentially excluding valid PDF files.
(So folks working offline won't go for hours dreaming they can overlay *.txt files, until after the finish writing the txt file, and try it, and it doesn't work.)
When recovering XRef streams, start with the stream with the largest
/Size rather than the largest offset.
Also, if reconstruction fails to find a trailer with a valid /Root entry
search for a root object.
Ghostscript 10.0.2 failed to handle the files changed in this commit,
but ghostscript 10.0.4 handles them fine as do earlier versions. These
files all have hybird xref in the form of a file with an xref table
appended with a section that has an xref stream. They all have
/PageLabels pointing to 107 0 R in the original file, with 107 higher
than the highest object. The spec says that this should be treated as
null, which results in /PageLabels null, which results in ghostscript
errors in that version. While ghostscript 10.0.2 may be handling the
file incorrectly, the file does something that's not really kosher,
and it's easier to fix the files, which had not been changed since the
very first open source release of qpdf, than to try to work around the
issue.
This was discovered with the GitHub actions runner was bumped to
Ubuntu 24.04, which contains the buggy version of ghostscript. I was
not able to find a specific ghostscript issue that addressed this, but
the problem went away in either 10.0.3 or 10.0.4.
Commenting out /PageLabels without changing offsets was a pragmatic
move to avoid having to regenerate the xref tables manually. I just
had to manually edit the binary xref stream to change the offset of
one item (the new object 1), which I put at the end to avoid breaking
other things.
Why did this ever work? Hard to say...perhaps a library we linked
against was setting `int _dowildcard = -1;` somewhere and no longer
is. Apparently linking with CRT_glob.o has been the way to do this for
a very long time, and we've just been lucky that it worked all this
time.
