[executor] Route the executor requests without the worker_to_worker interface

[huitseeker]

• the Executor's BatchLoader is using the network to retrieve batches from its own worker,
• that's too bad, because we have a BlockWaiter that allows a primary to retrieve payload from any particular block, feeding itself both on its own and on others' workers.
• but the very problematic thing with this is that the BatchLoader is using the WorkerToWorkerClient to issue these batch requests, which means that primary is impersonating a worker, in order to contact its own worker, and using the publicly network interface of its worker (as opposed to the loopback primary_to_worker interface).
• When the primary and worker are co-located, this round-trip through the exterior could be much more expensive than accessing a loopback interface.
• More importantly it would mean that the response packets coming out of the co-located worker are in a contest with the other requests coming from the outside. This would explain encountering the error messages "Failed to receive batch reply from worker ".

Conclusion: I think we should excise the WorkerToWorker network from the BatchLoader. A way to do that seems to be to mimic some of the behavior of the BlockWaiter to retrieve solely batches (rather than blocks). /cc @akichidis for better ideas.

[akichidis]

@huitseeker totally onboard in swapping the batch_loader with the block_waiter. By using block_waiter we also get on top transparent synchronization capabilities for missing batches. I don't believe we need to mimic block_waiter, we can just go ahead and use it. The executor is using the batch_loader to essentially request a "block" it self - meaning, all the batches associated with a certificate - and that's what we exactly do in the block_waiter.