Always run background jobs after a test publish

[Turbo87]

The original intent was that tests would be able to enqueue mutliple
actions and process them more asynchronously to act as more of a stress
test of the background worker logic. However, we have no tests explicity
testing such behavior and we can always add back such methods if we
decide to implement such tests.

This change reorders some requests in the http-data files. For the most
part requests are unchanged, however now if 2 versions of a crate are
published in rapid succession the HTTP index is guarenteed to see both
versions of that file.

Previously, if versions A and B were published they would both go in
the background queue. When the queue was processed, the versions would
be published to the git index and each of those jobs would enqueue an
HTTP sync. However, those syncs would occur after the two publishes and
so both syncs would see the full index file with both versions. This is
not an issue in production, as there is no requirement to push such
intermediate states to the HTTP index as long as it is eventually
consistent. In testing however, it is a bit more convenient to see the
more typical sequence of events.

Some tests now require the full test harness, even if a crate publish
is expected to fail.

Extracted from #5022