Add missing Send bounds for CursorIter.

[hdevalence]

This allows using the CursorIter in a Send future.

[QuietMisdreavus]

I'd like to add a changelog entry for this PR. Would you like to be credited?

[hdevalence]

This feels like a pretty minor change to me but I don't have any objection to being credited.

[QuietMisdreavus]

It feels like a notable enough change (an infrastructure type can be used in more places) that i would like to list it. Personal preference, i guess. :woman_shrugging:

[abonander]

@QuietMisdreavus I know it's a really small change for a minor version bump but would you consider publishing this? It can be worked around with tokio::task::LocalSet but it's a bit of a hassle.

Edit: nevermind, because LocalSet explicitly opts-out of Send as well... heck.

[abonander]

Addendum: there's still an issue, Sync needs to be added to the trait object as well if you're using .call() manually since it necessarily borrows &CursorIter<...> across an await point.

It looks pretty trivial to get rid of the trait object entirely though? Then it's not even a minor version bump as CursorIter will automatically be Send + Sync if T::Item is Send + Sync. I see though that FutureResponse is a bit more complex to deal with since it comes from an async fn.

It turns out Sync is not strictly necessary but you have to lift the .call() to an assignment before .awaiting on it, I guess since the reference is technically required to live for the whole statement otherwise:

let mut friends_cursor = egg_mode::user::friends_ids(...);

// won't compile if the encapsulating future is required to be `Send`
let friends_page = friends_cursor.call().await?;

// compiles
let friends_call = friends_cursor.call();
let friends_page = friends_call.await?;