Functionality provided by __NEOFS__NETMAP* X-headers seems unusable and unviable

[cthulhu-rider]

there are https://github.com/nspcc-dev/neofs-api/blob/cae99c9c6328250666f9e6944166cd8a4cc54cf8/session/types.proto#L143C6-L151, and:

1. i've never seen the client app using these headers (everything below explains why, practice confirms)
2. even if client will try, they are awkward to use. Client can and wants to operate with data objects and does not want to delve into the timeline
3. their use rather gives rise to abuse of servers, because does not collect anything from the client. Such queries are not taken into account in the economic model
4. headers are defined globally for all operations, although they are usable only for a couple of object ones

on the other hand, there is no workaround for the header functionality in the protocol. It can be thought of as a classification of the value of data. However, if it is not defined, then the storage system must provide the client with a service that considers all his data as equally (maximum) valuable. Being a client, having stored data in an object and paying for its safety, and also not being able to mark an object as “especially important” and “all others”, I expect the availability of data regardless of the timeline. For me, the current behavioral model provided by the protocol rather covers the shortcomings of the system implementation than allows me to transparently classify my data

finally, i suggest to unsrew mentioned X-headers from the protocol taking into account point 1. Other points put forward demands for a more developed model

[roman-khimov]

Refs. #117 and nspcc-dev/neofs-node#234. I agree that they're almost impossible to use correctly (when to use these options? How deep can I go? How deep should I go?). I don't think these headers classify anything though, it's just a fallback of some kind.

[cthulhu-rider]

if app needs deep-deep search, client has all (*) protocol tools for this:

1. try regular GET
2. if failed, get epoch from response and request previous network map
3. for each node from previous network map, send GET with TTL=1
4. if failed again, similarly goes into the past as much as needed

(*) almost all actually #257 (comment)

from one side, client insta sees container "unhealthiness", from the other side, he's still able to try to access the data