fix: assure excessive amounts of newlines can't lead to amplification.

Now we won't read more than 1024 newlines in a row, which leads to
a protection from specifically crafted configuration files which
can amplify themselves when large amounts of edits happen on them.

If somebody where to create a lot of sections based on one that
has a huge amount of newlines before it, this whitespace would
be retained with each new section, causing huge files to be created
in memory that cause great delays when writing the file back
and re-reading it.

Maybe there would have been a way to avoid copying excessive amounts
of whitespace when altering a section, or maybe one could also
have adjusted the fuzz-test that found it [1].
This would, however, have been much harder and time-consuming to
implement for dubious value.

[1]: https://oss-fuzz.com/testcase?key=6416843954782208

Author: Byron

gix-config/src/parse/nom/mod.rs

@@ -368,7 +368,7 @@ fn take_spaces1<'i>(i: &mut &'i [u8]) -> PResult<&'i BStr, NomError<&'i [u8]>> {
 }
 
 fn take_newlines1<'i>(i: &mut &'i [u8]) -> PResult<&'i BStr, NomError<&'i [u8]>> {
-    repeat(1.., alt(("\r\n", "\n")))
+    repeat(1..1024, alt(("\r\n", "\n")))
         .map(|()| ())
         .recognize()
         .map(bstr::ByteSlice::as_bstr)