The introduction of review request ownership changes made counters a bit

more complex, and for a time broke our outgoing counters. This was

largely addressed in commit abc032d20f3b286fb193df4a60340cf6dba8daa6,

but there was an edge case being hit by some users.
If a new owner's LocalSiteProfile didn't yet exist at the time they

were made the owner (such as if they had just been added to a

LocalSite but hadn't logged in yet, or were added by way of an auth

backend), then the initial values for their new profile's counters would

already be computed when fetched in _update_counts(), based on the

newly-published draft changes (which would include the ownership change,

and possibly reviewer changes). The outgoing counters would be worked

around from the previous fix, but incoming counters could be broken.
The same problems can also occur even without ownership changes, if the

user had created a review request and published via the API or some

other form of automation but hadn't yet logged in or triggered a code

path creating an initial profile.
This is hard to work around if the profile is being created in

_update_counts(), but the solution is pretty easy. We now ensure we've

fetched/created a profile before any part of the draft gets published,

giving us stable counters to work with as part of the publish and update

steps.
This fix lets us remove a bunch of special-cased updates in the previous

fix, and will take care of the various edge cases all at once.
Unit tests and docs have been enhanced to help us better reason about

these counters in the future.

Unit tests pass.