Support timeout values in client::register() and client::authenticate()

[Brisk4t]

Implements #65.

Not sure how much we care to keep tokio optional but guarded it just in case. I doubt there are any no_std implementations of this since both authenticate() and register() functions are async by default.

Note on updated rust-toolchain file:

I changed 1.85.1 to stable since i was getting version errors with icu_* and idna_adapter while building with the existing 1.85.1 but if we need to keep it pinned I could just make it 1.86 (which is the lowest supported version for those two crates), builds fine with stable though 🤷

[Brisk4t]

Updated the CI and crate toolchain version to 1.86.0 which is the minimum required version for crate deps failing in the build.

@Progdrasil I can make this a different PR in case you want to merge just the CI updates without the workflow checks since it will fail those until the toolchain update applies.

[Progdrasil]

Updated the CI and crate toolchain version to 1.86.0 which is the minimum required version for crate deps failing in the build.

@Progdrasil I can make this a different PR in case you want to merge just the CI updates without the workflow checks since it will fail those until the toolchain update applies.

Having it in this PR is fine for me, I just want to make sure this doesn't break for others downstream.

[Brisk4t]

1. For the semver check I don't think making the enum non-exhaustive is a good idea, but there doesn't seem to a catch-all cancellation timeout we can use either. Bumping the version of the client is my immediate impulse since its verbose.

2. Kinda derped on this, I'm running an older typeshare locally so I didn't check for version mismatch. Although i think it also makes a case for using stable rustc. The other option is to pin crate deps themselves but idk if there's any strong reason to.

[Progdrasil]

1. For the semver check I don't think making the enum non-exhaustive is a good idea, but there doesn't seem to a catch-all cancellation timeout we can use either. Bumping the version of the client is my immediate impulse since its verbose.

Yeah the version will need to be bumped, we can make it non-exhaustive so that future new errors don't cause a breaking change.

2. Kinda derped on this, I'm running an older typeshare locally so I didn't check for version mismatch. Although i think it also makes a case for using stable rustc. The other option is to pin crate deps themselves but idk if there's any strong reason to.

No worries, it probably because we don't install with the --locked flag. It's an update we'll do as a follow-up. Though to get the CI passing you'll need to update the CI to use rust 1.87 as well as the msrv.

[Brisk4t]

I checked past commits to see if the other crates all get a bump if one dep does but I couldn't find anything conclusive (transports is still at 0.1) so I'll leave that alone, just updated whatever semver + CI needed.