Tighter contract for FusedFuture

[Lucretiel]

The current contract for FusedFuture is not strict enough to be useful in practice. I'm running into this issue while writing first_ok, as described in #2110/#2031. For reference, this is a future that polls a list of futures and returns the first Ok result, dropping the rest, or if none return Ok, the last Err result. It's similar to select_ok, except that it doesn't return the incomplete futures after running.

My original thought was that, to avoid the overhead of manually tracking which futures have completed, I could use FusedFuture, and allow my consumers to use fut.fuse() to fuse futures that don't already implement it. However, FusedFuture::is_terminated is allowed to return true even if it hasn't yet returned a ready.

I'd like to propose either strengthening the current contract or adding a new trait or new method so that is_terminated (or a separate, new method, perhaps is_completed) ONLY and ALWAYS returns true if the future has polled Ready. The existing functionality could be retained as a separate method, as it could be used for optimizing pollers. A contract change would be breaking, but would probably lead to less confusion long-term than introducing a new trait, because of existing associations with FusedIterator.

See #1894 for related discussion.

[cramertj]

Hm, there are definitely things today that would return true from is_terminated even before returning Ready, such as future::pending.

[Lucretiel]

Follow-up: I'd be open to adding a new trait for this; my concern is that FusedFuture has a tight association with FusedIterator, which strictly implies that the underlying asset is "done" (returned Ready(T) or returned None). My view is that the existing FusedFuture should be given a softer name, like FutureWillFinish.

All that being said, I understand the need to not break backwards compatibility without sufficient cause, so I'd be totally open to a new trait called something like DidComplete

[cramertj]

Yeah, I understand that concern. I'm also pretty hesitant about propagating a second trait all throughout our codebase. cc @taiki-e @Nemo157 for their thoughts.

[taiki-e]

We can't propagate implementation properly until the (min) specialization is stable, so I think it's preferable to remove FusedFuture in the next major(minor) version. (i.e., always use .fuse())

[taiki-e]

Closing in favor of #2207, which propose the removal of FusedFuture. (See #2207 (comment) for a detailed description.)