Stream timeout seems too artificial and goes beyond the gRPC scope

[cthulhu-rider]

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

https://pkg.go.dev/github.com/nspcc-dev/neofs-sdk-go/client#PrmDial.SetStreamTimeout setting timeout for the single stream message. The implementation is here

i see following cons about the existence of such a setting from the user pov:

1. gRPC lib works with the full stream timeout only, single message timeout requires manual implementations
2. may conflict with the context timeout of the full operation
3. delaying one message can fail the entire stream in cases where messages could be delivered at the context "end"
4. the parameter is static for the Client and does not depend on the current state. Moreover, current state of the system/network load is not transparent to the user

Describe the solution you'd like

purge this parameter and rely on user context only. This approach is adopted in the gRPC, and it is a good abstraction from the details of data transmission in the form of a stream: the user understands the complete operation only.

Describe alternatives you've considered

still drop the parameter, and also we can try to invent restrictions under the hood based on a user deadline. But for this we need to first build a working model, which should be based on the transport properties reported by the server. For now, this seems to artificial, and single deadline around transport abstraction seems best to me

Additional context

i remembe the parameter during refactoring #636

[roman-khimov]

The main problem here is 1TB object GET. Per-request deadlines are perfect when objects are small. Once you have 1TB of data it becomes a bit different. What's the good timeout for this operation? Per-message timeouts allow to catch problems earlier in this case, but they're not perfect either.

[cthulhu-rider]

What's the good timeout for this operation?

there is no universal answer cuz GET user does not know the data size in general. If he is constrained by time, he will set a timeout for the entire operation. If not, there will be no deadline at all. Moreover, given the provided stream interfaces, the user can wrap his code with artificial deadlines himself. However, in almost all cases he will not want to do this