await
等待 ContinuousSessionProvider 的下一次 推送， 并在接收到时恢复一个结果 result。
val value = await(result)
// ...Parameters
一个响应 R
Throws
如果内部的管道已经被关闭或任务已经结束
如果内部的管道的接收已经被关闭
等待 ContinuousSessionProvider 的下一次 推送， 并在接收到时恢复一个由 result 计算的结果。
如果在 await 过程中出现异常，会在抛出此异常前， 将此异常使用 SessionAwaitOnFailureException 包装并恢复(resume)给 ContinuousSessionProvider.push。
val value = await { v -> v.toResult() /* 根据结果 value 计算一个结果 */}
// ...Parameters
Throws
如果内部的管道已经被关闭或任务已经结束
如果内部的管道的接收已经被关闭
等待 ContinuousSessionProvider 的下一次 推送 结果， 并将此结果和 推送]ContinuousSessionProvider.push 处的挂起点打包为 SessionContinuation， 并在稍后通过 SessionContinuation.resume 或 SessionContinuation.resumeWithException 恢复。
与 await {...} 相比，此函数可以延后 推送 挂起点 的恢复时机， 用来处理一些更灵活的逻辑。你需要更加了解对挂起点的相关操作，并确保能够在合适的时机恢复它。 否则，还是更建议使用 await { ... }。
val continuation = await()
val value = continuation.value
// 在异步中执行某些任务并稍后恢复结果
launch {
try {
val result = runTask(value)
continuation.resume(result)
} catch (cause: Throwable) {
// 出现了异常，恢复一个异常情况下的结果，
// 比如：
// continuation.resume(resultOnError(cause))
// 或者如此示例，直接恢复一个异常
// 这样对应的 `push` 处便会抛出此异常
continuation.resumeWithException(cause)
}
}.join() // 等待异步任务需要注意，上述示例中我们使用 Job.join 挂起了那个异步任务， 因为如果当 ContinuousSessionReceiver 内作用域已经结束 (completed), 而某个 推送 挂起点 尚未恢复， 则会直接使用一个异常恢复此挂起点。 因此，当你要在异步中延后恢复 推送 挂起点 时， 需要确保 ContinuousSessionReceiver 作用域尚未结束，例如使用 Job.join 或 coroutineScope 等。
See also
Throws
如果内部的管道已经被关闭或任务已经结束
如果内部的管道的接收已经被关闭