Use common timeout across the block_waiter/block_remover paths

[akichidis]

Description

We are using a few timeout configuration here and there already on multiple components when retrieving resources. Some examples:
the block_synchronizer timeout configs: https://github.com/MystenLabs/narwhal/blob/fdd4f0b45b1d9bf499fb7822d8e1d36144b09fe6/config/src/lib.rs#L141

Similarly we do have timeouts on the block_waiter:
https://github.com/MystenLabs/narwhal/blob/fdd4f0b45b1d9bf499fb7822d8e1d36144b09fe6/primary/src/block_waiter.rs#L29

block_remover
https://github.com/MystenLabs/narwhal/blob/fdd4f0b45b1d9bf499fb7822d8e1d36144b09fe6/primary/src/block_remover.rs#L33

especially when requesting entities, like a Certificate , we want to make sure that this adheres to a common timeout end to end. Example scenario:

I want to retrieve a certificate's payload via the get_collections gRPC endpoint. The endpoint on its own will bear a timeout configuration. Then the block_waiter will have its own timeout configuration. If the certificate is not available to the node, then the invoked block_synchornizer will attempt to fetch that from other peers and ensure (via submitting to core) that causal history is complete - separate timers used here as well. This can quickly become problematic with so many timers around which:

1. Makes configuration hard
2. We can't even easily predict what to expect in different scenarios
3. We can end up on conflicting timeout configs

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.