Allow 3 bytes of padding in the object retriever, not 2

[teor2345]

Ah right, I see what you’re saying. When we split an object at the exact length of the segment, we could end up reducing the length of its encoded size. Which would leave padding.

There is no custom logic to handle this padding, it just happens. So even if the encoded size goes down 2 bytes, we don’t try to fit another byte in there.

By the way, this means there’s a bug in the object retrieval code, because it assumes the padding is 2 bytes or less. But the archiver code can generate 3 byte padding if it splits a block that’s 2^14 bytes (or larger), and the length in the first segment is 63 bytes or less.

https://wentelteefje.github.io/parity-scale-codec/encode/#243-four-byte-mode

Originally posted by @teor2345 in #3318 (comment)