Copy binary header from local storage to GET/HEAD response without unmarshal

[cthulhu-rider]

Is your feature request related to a problem? Please describe.

to respond with local object header stored in BLOB storage, server:

1. reads full header binary into buffer
2. decodes it into SDK object structure
3. converts it to API object structure
4. encodes it into protobuf

in more detail, 1 includes:
1.1. format verification
1.2. memory allocation

each step (except perhaps 1.1) results in memory allocations. Although, given that BLOB storage keeps headers as protobufs, most of them are redundant

Describe the solution you'd like

read header protobuf directly into response message. This will reduce the number of allocations and speed up the execution

consider keeping 1.1

Additional context

#2925

[cthulhu-rider]

devenv, HEAD, local, 20 threads, 1 minute

head_local.pb.gz

[cthulhu-rider]

HEAD response carries header and signature fields only. So, when stably-marshalled object is read into buffer, we should skip object_id field and limit to payload field

one more thing to resolve is diff in field numbering:

• https://github.com/nspcc-dev/neofs-api/blob/c413a930a0f4f5fe86a61137062087480bf20a21/object/types.proto#L326-L330
• https://github.com/nspcc-dev/neofs-api/blob/c413a930a0f4f5fe86a61137062087480bf20a21/object/service.proto#L483-L487

so the fields must be renumbered before sending a response. This is a lightweight operation in this particular case

[cthulhu-rider]

i've drafted a version based on #3785. See top patch in the branch

i relied on unsigned responses because:

1. they are about to become so
2. signing on the single buffer would complicate patch implementation (though it is feasible)

also, in the patch version, I omitted response meta header. These are the protocol version + SN local epoch fields. Again, this is to speed up implementation. However, the omitted overhead is predictably small

also, i touched non-combined FSTree only again due to more obvious implementation. Presumably, the impact would be similar in the combined case

memory profiling results (#3783 (comment)):

• base base_allocs.pb.gz
• patch new_allocs.pb.gz

we can see the expected decrease in allocations of both space and objects

it's also worth noting that patch version processed 206_905 requests against base 101_108 ones. So, we can expect general RPS increase, too. Although it won't be that big in production envs