refactor task bridge to handle async tasks concurrently, preventing potential duplicate submission

[noot]

• previously, it appears that file validation (via handle_file_validation which includes the on-chain call to submitWork()) was being submitted multiple times for the same work (identified by hash). this was likely also happening for file upload as well. a potential cause of this is because the call to handle_file_validation was being tokio::spawned, so it was possible for multiple submission tasks for the same hash to be started
• refactor TaskBridge such that all futures run concurrently inside one select!{..} statement instead of being spawned
• store all handle_file_validation inside a tokio JoinMap, which stores the futures with the file hash as the key. thus duplicate handle_file_validation calls cannot run at the same time.
• this assumes that the issue is not due to the task bridge receiving the same file on the socket twice, in which case, the on-chain submission would still happen multiple times and only the first would pass.

closes #596

[JannikSt]

Nice! This looks a lot more solid. Same for this change on the task bridge I would actually run this on a real GPU now with a proper workload for testing before merging this.
Also what do you think of using FuturesUnordered instead of the JoinSet that requires tokio unstable?

[noot]

@JannikSt going to copy paste my response here: I'm using JoinMap which is already using tokio unstable. I can change the JoinSets to FuturesUnordered<JoinHandle> which is mostly the same as JoinSet, and the JoinMap to a hash map + FuturesUnordered<JoinHandle>, but the ergonomics are not as good imo. is your issue with using tokio unstable?

[JannikSt]

minor comment - otherwise good to go!

[JannikSt]

this is no longer required right?

[noot]

no, will remove!