Fix data-race in folly::coro::detachOnCancel

Summary:
the relaxed memory order on the atomic exchange operations in detachOnCancel
does not enforce a happens-before relationship between the release of the
unique_ptr and the visibility of the exhanged value.  This means that any
future accesses to the unique_ptr will actually (technically) race with its
destruction.  This was causing failures in at least one test case for cpentity.

A more detailed writeup of the investigation can be found here:
https://fb.workplace.com/groups/cpentity.investigations/permalink/9858481294195756/

The change from relaxed to acq_rel consistency should have no performance
impact on x86 systems (due to the TSO memory ordering), and likely neglibile
impact on systems with weaker memory models.

Reviewed By: iahs

Differential Revision: D73457949

fbshipit-source-id: 0ef02486069db59396192a2f04b64dc78bdf551a

Author: David Devecsery

third-party/folly/src/folly/coro/DetachOnCancel.h

@@ -62,7 +62,7 @@ Task<semi_await_result_t<Awaitable>> detachOnCancel(Awaitable awaitable) {
         .startInlineUnsafe(
             [postedPtr = posted.get(), &baton, &result](auto&& r) {
               std::unique_ptr<std::atomic<bool>> p(postedPtr);
-              if (!p->exchange(true, std::memory_order_relaxed)) {
+              if (!p->exchange(true, std::memory_order_acq_rel)) {
                 p.release();
                 tryAssign(result, std::move(r));
                 baton.post();
@@ -74,7 +74,7 @@ Task<semi_await_result_t<Awaitable>> detachOnCancel(Awaitable awaitable) {
   {
     CancellationCallback cancelCallback(
         co_await co_current_cancellation_token, [&posted, &baton, &result] {
-          if (!posted->exchange(true, std::memory_order_relaxed)) {
+          if (!posted->exchange(true, std::memory_order_acq_rel)) {
             posted.release();
             result.emplaceException(folly::OperationCancelled{});
             baton.post();