try_tick considered harmful

[notgull]

It is my current opinion that try_tick is almost never useful for the purposes that I've seen people use it.

The intended purpose is for FFI interop with other runtimes. Even then it's use case is niche. You almost never want to pop a task off of and not be notified of the next task later. In the worst cases it lends itself to creating a spin loop, where someone polls try_tick in a loop.

Even in the best cases the patterns that it creates are buggy. Here are issues caused by the misuse of the ticking APIs.

• https://github.com/orgs/smol-rs/discussions/298
• Add hook to be called when new pending task is available #44
• No doubt constant misuses of this function in production code that is never reported.

For its intended use case of FFI interop, using tick() with a waker that wakes up the event loop that it's in is the preferred option. Even then run() would be the preferred option, as it runs forever.

My intention is as follows:

• Mark try_tick as deprecated.
• In the next breaking release of async-executor remove try_tick.
• Specify in documentation that run is the preferred way of driving the executor.
• Specify in the documentation that tick and try_tick are exclusively used in executor interop, and that pure smol use cases should use run().

[mintlu8]

I think try_tick is pretty useful to make an executor run statefully inside a non-async event loop like winit's.