Do not rely on async/wait for synchronous fetch replication

Before this change, the request for a sync FetchAction was triggering
an async schedule of a replication task, with a replication delay of
zero.

The consequence was the blocking of the client thread for an async
replication that, potentially, could have been stuck in the queue
waiting for other async replication to complete.
Scheduling a replication task does not guarantee that the fetch will
start immediately because it is influenced by the whole logic behind the
replication queue mechanism:
- waiting for the runway
- being aggregated with an existing pending task
- appended to the bottom of the replication queue

When the client requests a sync replication, it typically has other
client resources associated and locked that won't tolerate the async
execution. Faking a sync execution with async/wait for a Future to
complete would not allow the client resources to be released.

Skip the replication queue altogether and rely on the direct
FetchOp execution when the client REST-API FetchAction call has
requested synchronous execution.

Bug: Issue 304123378
Change-Id: Ia9171dc9525f2543ba16b1eb78308b0580839cbf
11 files changed
tree: 02c953f97afa8b1dac8c816534ec8e82babb3c8f
  1. example-setup/
  2. src/
  3. .gitignore
  4. BUILD
  5. Jenkinsfile
  6. LICENSE