-- Without concurrency in mind, what do we want to do:
                    --
                    --   * check if a URA exists
                    --   * if not:
                    --       - insert new RA
                    --       - done
                    --   * if yes:
                    --       - get all the URA's unlinked deliveries
                    --       - delete them from DB
                    --       - insert new RA
                    --       - insert linked deliveries for them
                    --
                    -- but with concurrency present, we can easily ruin things.
                    --
                    -- The goal is that when the periodic delivery runs, and
                    -- reads all the unlinked deliveries not already running,
                    -- it doesn't need to check whether their URA since got a
                    -- matching RA. It doesn't need to, because whenever a new
                    -- RA gets inserted, all unlinked deliveries switch to
                    -- linked, and probably the URA gets removed. So, we don't
                    -- need to worry about it.
                    --
                    -- Is this requirement even possible? I like to think that
                    -- it is: There's exactly 1 place now where actors get
                    -- fetched, and that place is right here. So we have a
                    -- chance to maintain such conditions.
                    --
                    -- So, once we've fetched our nice little actor, which
                    -- things may be happening concurrently?
                    --
                    --   * In outbox post handlers, unlinked deliveries may be
                    --     running, waiting for us to give them the new RA
                    --   * In the periodic postman, unlinked deliveries many be
                    --     running, waiting for us to give them the new RA
                    --   * New unlinked deliveries may get inserted. If the URA
                    --     has 'since' set, outbox post handlers may skip
                    --     trying to fetch the RA, and instead just proceed to
                    --     inserting UnlinkedDeliveries.
                    --   * Hmmm UnlinkedDeliveries might get deleted? Because
                    --     the URA has been unreachable for too long.
                    --   * We might have unlinked deliveries in running state,
                    --     but which aren't waiting for us. For example, they
                    --     got inserted to the DB, but haven't reached the
                    --     point in the code, where they readMVar.
                    --
                    -- Once we commit the RA insertion, there will be no new
                    -- uses for the URA. We may need to adapt some code to
                    -- allow for RA and URA to coexist though, unless we can
                    -- guarantee here that it's never the case.
                    --
                    -- Persistent's 'delete' does nothing for nonexistent
                    -- records, so we can safely delete things here even if
                    -- they'll get deleted again while running deliveries.
                    --
                    -- So, again, the situation is that if a URA exists, we
                    -- want to:
                    --
                    --       - get all the URA's unlinked deliveries
                    --       - delete them from DB
                    --       - insert new RA
                    --       - insert linked deliveries for them
                    --
                    -- The unlinked deliveries that currently exist in the
                    -- database may be:
                    --
                    --   * Just got inserted by outbox post, and done with
                    --   * Just got inserted by outbox post, and in a bit
                    --     they'll be waiting for us
                    --   * Got inserted by outbox post and waiting for us
                    --   * Resting in DB, waiting for periodic run
                    --   * Got picked by periodic run, some about to be deleted
                    --     due to unreachability and some will do
                    --     fetchRemoteActor and eventually wait for us
                    --
                    -- All the deliveries that are going to look for an RA, we
                    -- don't have to worry about them. Because whether they
                    -- wait for us or grab the RA from the DB after we finish,
                    -- they'll switch to a linked Delivery and stop using the
                    -- URA. I think.
                    --
                    -- Irony: This very piece of code may be running because
                    -- some unlinked deliveries want the RA. So, both them and
                    -- us and going to worry and switching from UDL to DL?
                    --
                    -- In outbox post, they'd be delivering new UDLs where the
                    -- URA is either new, or it's "since" is Nothing. But when
                    -- they run us, why not switch *all* the UDLs for that URA
                    -- to DLs?
                    --
                    -- What if we decide, that we do all the UDL-to-DL
                    -- switching here?
                    --
                    -- Let's check the outbox post code, would it be okay?
                    --
                    -- The behavior after fetchRemoteActor, if we ignore the
                    -- try-one-per-host optimization, is:
                    --
                    --   * If it fails, update the URA's "since" to Just now,
                    --     and UDL's "running" to False
                    --   * If successful, try to deliver to inbox:
                    --       - If fails: update RA's "since" to Just now,
                    --         delete the UDL and insert a DL
                    --       - If success: delete the UDL
                    --
                    -- So what we could do in fetchRemoteActor is:
                    --
                    --   * If fetching fails, update URA "since" to Just now,
                    --     if it was previously set to Nothing
                    --   * If fetching succeeds, ummmm this is a problem. We
                    --     Right now, a UDL stays existing until after delivery
                    --     to inbox. This means, we can't delete UDLs right
                    --     after fetching RA. Alternatively, we could decide
                    --     that upon RA fetch, we instantly delete the UDL and
                    --     insert a new DL, and only then, we try to deliver to
                    --     inbox. So, we delete all the UDLs here? But that
                    --     means we must insert new DLs for them, right? We
                    --     can't just delete. The code that waits for the RA
                    --     though, what is it supposed to do? I guess instead
                    --     of inserting a DL, it will require to *fetch it from
                    --     the DB*.
                    --
                    -- So, summary of changes:
                    --
                    --   * If fetching fails, update URA since
                    --   * If fetching succeeds, delete all URA's UDLs, delete
                    --     URA, insert RA, insert DLs