Store large objects hashes in the link object payload

[roman-khimov]

1. No matter what particular limit we're to choose in Object header size limitation #262 it'll be too low. We can't have arbitrarily large headers and even 4M headers only allow to have 8T objects. Yeah, they're big, but some HDD image can already easily be larger than that. And this 4M header is already impractical enough to operate with.
2. Typical object payloads are 64M and that's enough for roughly 128T object. Seems to be good enough for today, even though it doesn't blow your mind.
3. While I still think link objects should be simple, we can at least theoretically make them large as well, effectively removing this limit at all.

We can't break old objects, so split header can still remain (and arguably it can be more effective for smaller objects with 2-50 parts), but we need a new link object format with hashes stored in its payload. We can even do this without many changes to the wire protocol, just specify that missing "children" list means that hashes are encoded in the payload. Encode them without any wrappers, plain 32 bytes values one by one.

[cthulhu-rider]

overall looks good, but

Encode them without any wrappers, plain 32 bytes values one by one

will tie our hands on a potentially necessary expansion of the format in the future. If for some reason there is no desire to define a clear structure of this data (which I consider more like saving on matches than justified), then let's leave at least the 1st byte as a marker: let 0 mean hash concatenation

[roman-khimov]

This can be tied to the version of the object itself.

[cthulhu-rider]

really can, I don’t think it’s more convenient, but it’s better than nothing

[roman-khimov]

See also #264.