Revise PUT load registry storage

[carpawell]

Expected Behavior

PUTing an object to NeoFS should do put an object to NeoFS not something else:

iteration_duration.......: avg=2.01s min=277.33µs med=1.76s max=18.59s p(90)=2.85s p(95)=3.51s
...
neofs_obj_put_duration...: avg=1.97s min=641.68ms med=1.72s max=18.52s p(90)=2.8s  p(95)=3.43s

Current Behavior

Sometimes it is possible to get such results:

iteration_duration.......: avg=6.94s min=270.07µs med=6.32s    max=27.76s p(90)=11.46s p(95)=13.61s
...
neofs_obj_put_duration...: avg=1.38s min=608.86ms med=948.46ms max=18.71s p(90)=2.07s  p(95)=3.44s

An average iteration exceeds NeoFS network part more than 4 times.

Possible Solution

Do not write objects to a local registry. See also how good an object generation is.

Steps to Reproduce (for bugs)

Just repeat and repeat and repeat load with a registry turned on and wait until iteration_duration and neofs_obj_put_duration differs enough not to make results believable.

Context

Sometimes PUT load may have extremely low speed and it does not seem like a NeoFS error: xk6 just does not provide a satisfying load.
NOTE: could be fixed in #67. Should be rechecked.

[carpawell]

Maybe add some metrics that say what time registry operations take.

[roman-khimov]

Do not write objects to a local registry

I have not looked at its internals, but it seems to me we need this registry for subsequent object fetching. But does it need to be stored anywhere or in-mem map will suffice is an open question to me.

[carpawell]

I have not looked at its internals, but it seems to me we need this registry for subsequent object fetching.

Yes, it is needed only if we are PUTting and GETting objects at the same time. So we are testing a storage and using another storage for it with undefined (by default) i/o latency (from an object iteration point of view). So in-mem may look better, yes.