Some queries require to perform several I/O action in a sequence before responding to the client.

Between each action, we decrease the timeout in order to track precisely the elapsed time to honor the timeout input from the client.

This logic triggers two different failure modes for the remote shard when:

• the timeout is zero:
  • the remote shard does not accept timeout=0 as input
• the timeout is between 0 and 1 sec
  • given that the value is floored, it triggers the previous case as well

This PR proposes to:

• gate the access to remote shard with non zero timeout to shortcut the query processing
• round up the timeout value to the next greater integer.
  • e.g 0.5 sec would become 1 sec instead of timing out
• unify our timeout param. value with the one used for the gRPC connection timeout

This gives the following change:

The new approach is more lenient as it gives more time to finish to all requests.