fix: create raceAndCancelPending proc

[diegomrsantos]

The race proc in chronos doesn't cancel the remaining futures; sometimes that's what we need to do. This PR creates a proc that executes a race between a provided sequence of futures and cancels any remaining futures that have not yet been completed.

Related to #1165 and #1170

[richard-ramos]

This looks useful, and perhaps should exist in chronos 🤔

[vladopajic]

raceAndCancelPending should return future that finished the race, aka result from race, because one might need this future.

[arnetheduck]

it should indeed, mostly because race is declared that way - that said, returning the future is actually of limited use since the value type is lost - most uses of race end up discarding it and using the "original" instance.

The other risk is that one forgets that more than one future might be finished by the time race resumes.

[vladopajic]

how about raceAndCancelPending -> raceAndCancel ?

[vladopajic]

This looks useful, and perhaps should exist in chronos 🤔

seems better suited for cronos.

@arnetheduck wdyt?

[arnetheduck]

there is no need for finally .. in particular, if race is cancelled, it should not cancel futs to maintain the race contract in general - ValueError means there are no futures, so nothing to cancel either

[arnetheduck]

This looks useful

It looks useful, but the question is whether it is useful ;) It would be good to see a motivating example where it's actually put to use before adding to chronos proper - ie where in libp2p would you use it, for example?

[vladopajic]

This looks useful

It looks useful, but the question is whether it is useful ;) It would be good to see a motivating example where it's actually put to use before adding to chronos proper - ie where in libp2p would you use it, for example?

closest usecase:
https://github.com/vacp2p/nim-quic/blob/e5bcee4b909a9924fa6fbea305884888ce466330/quic/connection.nim#L173-L202

[arnetheduck]

closest usecase:

This is a classic example of the trap I mentioned - even if the handshake completes successfully by the time the race finishes, the code might prefer to treat it as a timeout which often isn't what you want - but more than that, it's worth rewriting the code to use raceOrCancel in a few different situations to see that it truly works (with all the generics, error conditions etc) and that the outcome really looks better - it's a lot easier to add things to chronos (and libp2p btw) than it is to remove them, so we want to make sure the ergonomics have been practically stressed before adding too much