Check --await and --timeout interaction

[fyrchik]

Check how they interact and describe the behavior.
Maybe add --await-timeout

[carpawell]

Now we wait for ~120 seconds before saying "timeout: *smth* has not been *actioned* on sidechain"

I think we can go three ways:

1. Keep it as it is now: (--timeout is for network operations only and pooling timeout is a const);
2. Make pooling timeout as max(120, --timeout) (if timeout is set);
3. Add a new --await-timeout, just +1 flag.

I'm somewhere b/w 1 and 3, did not think that --timeout could be interpreted as a pooling timeout before, and do not like adding more flags that mean nothing (neofs-container create can be called with --await-timeout 5 while the block time is 15s so what the expectations are?)

/cc @fyrchik, @cthulhu-rider, @anikeev-yadro, @realloc, @acid-ant

[acid-ant]

I vote for 3, we can specify in help value for default timeout 15s to warn about using 5.
Also we can provide option to configure number of retries and sleep interval between each retries. Like --await-retries and --await-sleep-timeout

[cthulhu-rider]

I'd leave single timeout for the command since user doesn't care what's going on inside. Awaiting option just tells to finish successfully if container is persisted only, so it doesn't have any relation to timeout. With --await we can clarify the output when request is sent but the operation hasn't persisted yet (I don't remember how is it going now).

[fyrchik]

1. What about using --await 2m, i.e. always using explicit timeout?
2. What about making --await and --await-timeout mutually exclusive?
3. Or just use both --await and --await-timeout.

[carpawell]

IMO, the best for us is 1. if it is possible to do without breaking compatibility.

[roman-khimov]

1. Timeout should be global, per CLI operation. Internals are opaque to the user, he can't know how many of different requests are being made for his specific operation.
2. --await should work as it should work, just waiting for event/VUB (not some specific time), irrespective of --timeout.
3. Sane defaults should be used to cover most of the regular --await cases. Default timeout with --await may differ from the one without it.
4. Commands should make it clear that the request was successfully sent when that's the case, but they failed to --await.
5. Other than that, insufficient non-default timeouts are user's responsibility.