GET errors after partial data

what is the difference b/w returning a status error from InitGetObjectStream and returning a status from the reader later?

Originally posted by @carpawell in #4067

i propose to review all GET code on the topic of reaction to a status error following some non-empty data. Currently, GET stream can end with any status. But this is not valid in all cases

there are 3 normal results:

1. everything is OK: server streams [header] + [payload] with OK status in all response messages
2. object is unavailable (not found, removed, etc.): server responds with corresponding status with no data
3. stream cannot be finished: server responds with INTERNAL or CONTEXT status

usually client or proxy node just pipes data as it goes

but some cases can be confusing. For example:

1. header is received
2. several chunks are received, but not all
3. 404/removed/other status

in these cases, when SN is a client working w/ container placement generally including multiple servers, it should abort the stream. For normal cases above, SN can memorize the progress and continue w/ reserve server

Start by tracing InitGetObjectStream, the reader path, and the other GET code that handles status errors after non-empty data. Compare the three normal outcomes with partial streams ending in 404, removed, INTERNAL, or CONTEXT status. Done means the client or proxy consistently aborts invalid partial results while preserving progress for resumable normal cases.