Adjust Async cancellation to CE 3.5

[kciesielski]

Fixes #2892

The crucial change in CE 3.5 is that now async_ is uncancellable, which may lead to deadlocks. It also affects Async[F].fromFuture which relies on it underneath, as well as async, which becomes uncancellable when returning a None.

This PR revises our usages of async and friends in order to add proper explicit handling for cancellation where needed.

1. ArmeriaCatsServerOptions[F]
   Creating and deleting temp files for Armeria is now converted to async with an attempt to cancel the underlying Java Future.
2. Armeria's CatsFutureConversion now uses CE's fromFutureCancelable, with empty cancellation logic. The underlying Future cannot be canceled, but at least we remain consistent with previous behavior - the fiber that awaits for async callback can be canceled, preventing deadlocks.
3. Finatra Futures are now converted to F using async, plus a cancellation callback which tries to interrupt the underlying Finatra Future (future.raise(...))
4. Vertx Future to F conversion is also now using async, with a no-op cancellation logic, but at least it should keep previous behavior and avoid deadlocks.

---

• Implementation
• Adjust docs
• Adjust tests

[adamw]

shouldn't we wait for the future, but then wait for its result, to properly implement cancellation integration?

[kciesielski]

You mean call the cancel but still block until the future completes? I think the finalizer should finish as soon as it finishes its logic. Take a look at this example from The Async documentation:

def fromCompletableFuture[A](fut: F[CompletableFuture[A]]): F[A] =
  flatMap(fut) { cf =>
    async[A] { cb =>
      delay {
        //Invoke the callback with the result of the completable future
        val stage = cf.handle[Unit] {
          case (a, null) => cb(Right(a))
          case (_, e) => cb(Left(e))
        }

        //Cancel the completable future if the fiber is canceled
        Some(void(delay(stage.cancel(false))))
      }
    }
  }

[adamw]

I thought that the idea in cats-effect is for the finalizers to block until the effect finishes (after cancellation or not). But the example indeed suggests otherwise.

... and reading https://github.com/typelevel/cats-effect/releases/tag/v3.5.0 your code is correct :)

[adamw]

aren't twitter futures cancellable? (it's a distinct operation from raise)

[kciesielski]

I guess it was called cancel() in older versions, but now it's this raise method https://github.com/twitter/util#future-interrupts

[adamw]

Ah ok thanks :)

[adamw]

isn't this fake cancellation logic - shouldn't we wait for f to complete?

[kciesielski]

If we want to wait for f to complete then we should return None here, which basically means leaving async_ as before. The difference is that:

• in older CE (<3.5) canceling such a fiber would not wait for the future and finish immediately (leaving a leaked future)
• in CE 3.5 this IO is uncancellable, leading to potential deadlocks

If there's no way to cancel underlying future, we need to choose between keeping the previous behavior (canceling the outer fiber and leaving a leaked future) and agreeing to the new uncancellable behavior. I chose the first solution to keep consistent with previous behavior.

[adamw]

Ok, well I guess if we can't do anything, we can't :)

[katlasik]

lgtm