fix: swap_vanity_urls() works predictably with unset vanity URLs

[toph-allen]

Intent

Update swap_vanity_url() with numerous fixes and changes. Changes include:

• When swap_vanity_url() was called on a piece of content without a vanity URL, the content item set to receive that would instead receive a randomized placeholder URL. Now the function works as intended when one content item has no vanity URL: the other content item receives an unset vanity URL!
• Better error handling. Previously, errors were not handled gracefully, so if the caller did not have permission to modify the second content item, the first content item was left with its randomized placeholder URL. Now, errors are called out correctly and any changes made are rolled back.
• Names! It is now called swap_vanity_urls() because you're swapping two vanity URLs between two content items. The arguments are now called content_a and content_b because the old argument names, from and to, don't make sense when vanity URLs move from and to both items. The old function name remains but is deprecated, and just shims argument and return object names to the new function.

Fixes #360

Approach

Rewrote the function's internal workflow. Pseudocode:

1. Get both content item's current vanity URLs.
2. Delete each content item's vanity URLs, each inside a tryCatch statement. If content_a fails, stop and err. If content_b fails, restore content_a's original vanity URL and err.
3. Assign each content item the other's URL. We now know these operations will succeed, because delete and set have the same permissions.

Perhaps a better approach would be to call set_vanity_url(content_a, vanity_b, force = TRUE) in 2., as this doesn't risk the (admittedly very unlikely) case that another piece of content snipes the URL before it's reassigned. But this actually introduces more complexity:

• We'd have to do conditional logic to know if we needed to set or delete in this step.
• Because force = TRUE also modifies content_b's vanity URL, if we lacked permission to modify content_b, that operation would fail — but only if content_b initially had a vanity URL (if its vanity was unset, we'd just be unsetting vanity_a's URL). So the workflow for rollbacks would be much more complex, and harder to reason about / test / maintain.

Checklist

• Does this change update NEWS.md (referencing the connected issue if necessary)?
• Does this change need documentation? Have you run devtools::document()?

[toph-allen]

So that it returns an error if it receives an HTTP error status.

[tdstein]

Since these transactions aren't atomic at the database level, there is no way to ensure the swap happens successfully. Nevertheless, these types of fallbacks are nice to have.

If logging is established in this project, I would add a log info statement describing each step as it happens. That way the user knows A was reset to its original state.

[tdstein]

Nice, this is a good idea. The server does mutate the submitted vanity url in some cases (i.e., leading '/').

[tdstein]

Logical ✅
Test coverage ✅
Documentation ✅

Looks good to me!