support async failpoints

[tabokie]

• Added async_fail_point macro, it's usage is exactly the same as fail_point, but must be placed in an asynchronous context.
• sleep and pause command sent to the async fail point will not block async runtime.
• In addition, cfg_async_callback is added to inject custom async logic.

Signed-off-by: Xinye [email protected]

[sticnarf]

I do worry this is not user friendly enough.

Maybe we can spawn a thread and send a signal after sleep some while to implement this without depending on any async runtime.

[tabokie]

Done

[BusyJay]

Seems duplicated with #58.

[tabokie]

Seems duplicated with #58.

From the looks of it, #58 doesn't support async sleep and runtime async callback. This PR supports them, but doesn't support specifying a compile-time async callback (the one implemented in-place with fail_point).

I can't figure out an elegant way to unify async and sync version of fail_point!(name, callback). And I'm reluctant to go with #58 and make all fail_point!(name, callback) return async blocks, because most of the time that isn't necessary. If the user want to inject custom async logic, they can always use the more powerful cfg_callback.

[waynexia]

I can't figure out an elegant way to unify async and sync version of fail_point!(name, callback). And I'm reluctant to go with #58 and make all fail_point!(name, callback) return async blocks, because most of the time that isn't necessary. If the user want to inject custom async logic, they can always use the more powerful cfg_callback.

FYI, #58 defines two macros for sync (fail_point!()) and async(async_fail_point!()). It won't affect existing code.

[tabokie]

I can't figure out an elegant way to unify async and sync version of fail_point!(name, callback). And I'm reluctant to go with #58 and make all fail_point!(name, callback) return async blocks, because most of the time that isn't necessary. If the user want to inject custom async logic, they can always use the more powerful cfg_callback.

FYI, #58 defines two macros for sync (fail_point!()) and async(async_fail_point!()). It won't affect existing code.

I see, it is a slightly different mental model. Your idea is to only use async_fail_point when user want to inject async code. My idea is to always use async_fail_point in async context. In practice the latter is more versatile because we might not know what to inject beforehand.

And continue with my idea, it becomes important to allow user to write async_fail_point(name, || { Ok(()) }) instead of async_fail_point(name, || { async { Ok(()) } }.