investigate and fix snappy stream encoding of a big bellatrix block which was rejected by the lighthouse bn

[g11tech]

Pawan from lighthouse raised an issue where there snappy decoder rejected a lodestar encoded block. Apparently it was a big bellatrix block from goerli shadowfork 2.

Investigation Updates:

• After a bit of joint setup and investigation, pawan came up with theory that it was because of the snappy stream specification where a decoded/uncompressed chunk can't be > 65k bytes, and this particular block was around 130k bytes.
• Was able to stream decode the provided data, as suspected it was just 1 chunk, was able to successfully ssz decode bellatrix block
  
• Chunkified the uncompressed data into three chunks and reencoded it as a stream and dumped it into a file. Passed that re-encoded chunkified stream against the test code to confirm that it was now being decoded as 3 chunks (60k,60k,13k) something bytes. Provided the file to pawan over discord for him to run through his decoder and confirm
• Waiting on Pawan/Lighthouse team for confirmation on the chunk post, details here in comment

Expectation: Upon successful confirmation from Pawan/lighthouse regarding the successful decoding of the chunkified stream, do a PR in lodestar to chunkify the snappy stream payloads as well as add tests for the same using the same block data

[g11tech]

lighthouse <> lodestar chunked encoding/decoding status

• Aparently, lighthouse is getting checksum error on the chunked stream encoded data by lodestar.
  However the my decoder able to decode lighthouse chunk encoded data correctly. So apparently, there are two differentt encodings for the same uncompressed data.
  Verified that the decoder was correctly decoding two different encodings/compressions into the same data.
• Check using other libraries/with other CLs