Add constraints on large header size; malicious input could cause OOM

[frewsxcv]

Reading this slice of bytes into the Rust FgbReader will cause memory exhaustion on my machine:

let input: &[u8] = &[102, 103, 98, 3, 102, 103, 98, 0, 39, 39, 39, 39, 39, 39, 39, 39, 39, 39, 39, 39, 39, 219, 216, 216, 216, 216, 216, 216, 216, 39, 39, 39, 39, 39, 32, 39, 39, 39, 39, 39, 39, 39, 39, 39, 10, 169, 247, 247, 247, 247];

Live Heap Allocations: 681051920 bytes in 616 chunks; quarantined: 82746 bytes in 35 chunks; 151073 other chunks; total chunks: 151724; showing top 95% (at most 8 unique contexts)
656877351 byte(s) (96%) in 1 allocation(s)
    #0 0x11016021d in wrap_malloc+0x9d (librustc-nightly_rt.asan.dylib:x86_64+0x4521d)
    #1 0x10e2188bf in flatgeobuf::file_reader::FgbReader::open::h4507c5254c3f3c4e+0x22f (read:x86_64+0x1000018bf)
    #2 0x10e22b34a in rust_fuzzer_test_input+0x62a (read:x86_64+0x10001434a)
    #3 0x10e22d4ce in __rust_try+0xe (read:x86_64+0x1000164ce)
    #4 0x10e22d163 in LLVMFuzzerTestOneInput+0x133 (read:x86_64+0x100016163)
    #5 0x10e2300c1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long)+0x131 (read:x86_64+0x1000190c1)
    #6 0x10e22f45d in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*)+0x3d (read:x86_64+0x10001845d)
    #7 0x10e231979 in fuzzer::Fuzzer::MutateAndTestOne()+0x249 (read:x86_64+0x10001a979)
    #8 0x10e2329c5 in fuzzer::Fuzzer::Loop(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&)+0x385 (read:x86_64+0x10001b9c5)
    #9 0x10e25351f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long))+0x210f (read:x86_64+0x10003c51f)
    #10 0x10e262d42 in main+0x22 (read:x86_64+0x10004bd42)
    #11 0x7fff20346630 in start+0x0 (libdyld.dylib:x86_64+0x15630)

MS: 1 EraseBytes-; base unit: 5689a55a7e79130882f4b9a5e56078827298d1e0
0x66,0x67,0x62,0x3,0x66,0x67,0x62,0x0,0x27,0x27,0x27,0x27,0x27,0x27,0x27,0x27,0x27,0x27,0x27,0x27,0x27,0xdb,0xd8,0xd8,0xd8,0xd8,0xd8,0xd8,0xd8,0x27,0x27,0x27,0x27,0x27,0x20,0x27,0x27,0x27,0x27,0x27,0x27,0x27,0x27,0x27,0xa,0xa9,0xf7,0xf7,0xf7,0xf7,
fgb\x03fgb\x00'''''''''''''\xdb\xd8\xd8\xd8\xd8\xd8\xd8\xd8''''' '''''''''\x0a\xa9\xf7\xf7\xf7\xf7
artifact_prefix='/Users/coreyf/tmp/flatgeobuf/src/rust/fuzz/artifacts/read/'; Test unit written to /Users/coreyf/tmp/flatgeobuf/src/rust/fuzz/artifacts/read/oom-fee1960a9368951f58513973b2c8002cc219f1e4
Base64: ZmdiA2ZnYgAnJycnJycnJycnJycn29jY2NjY2NgnJycnJyAnJycnJycnJycKqff39/c=
SUMMARY: libFuzzer: out-of-memory

A couple options:

• Hard limit on max header size
• Customizable limit on max header size via a new FgbReaderBuilder

Discovered while fuzzing via #84

[bjornharrtell]

For reference there is a hard limit set in the GDAL driver implementation, see https://github.com/OSGeo/gdal/blob/42979b8faad298a7450da22c1a8153f2c7c65e02/gdal/ogr/ogrsf_frmts/flatgeobuf/ogr_flatgeobuf.h#L46. It was also a mitigation to fix a bug caught by fuzzing.