Aggregator setup pipelining

[doscortados]

Closes #460

[mmtftr]

Thanks a lot for the changes.

I believe the original issue also wants the try_join_alls to happen in background tasks so that they're happening in parallel (you can check aggregator for details)

We're also going to be working on moving the business logic out of the gRPC handlers, and moving parsing/validation logic out into trait impls so that they're more easily tested and the code has less clutter.

[mmtftr]

Thanks a lot, these will reduce boilerplate by a lot.

I think the naming needs to change though, this seems like a utility function that calls all clients with a given func and returns the inner response. Something like: map_clients_collect?

Also maybe #[inline] and/or #[track_caller] are appropriate here.

[doscortados]

Yes, this definitely needs refining, thank you for pointing it out. I didn't find an elegant way to generalize it over streaming (returning Streaming<T>) and regular/non-streaming (returning Response<T>) requests 🤷 .

[mmtftr]

I think we need docs on the behavior. This currently collects until end of stream unless an error happens, in which case we prematurely return the error. I think collect fits better here. This is also the behavior of collect when doing a Iter<Item = Result<T, E>> -> Result<Vec<T>, E>

Also can we move these two into another module?

[doscortados]

Thank you, this was just a first attempt to generalize stream collection, probably just .collect() on a stream would have been enough and this function is unnecessary.

[doscortados]

Thank you for the comments @mmtftr , and sorry for my late reply!
This is rather initial version and significant re-work will follow in further commits.

At this point I see that mpsc channel isn't working out for multiplexing N-over-M streams, and I am trying out mpmc one to avoid pulling all the params in memory before streaming it to consumers.