The avatar registry, when running for the first time against a site

configuration from an older version of Review Board, would attempt to

migrate the gravatar settings over and then save the site configuration

back to the database. When threads spun up, they'd all load their site

configuration and then write it back out, invalidating all their states

and forcing reloads, which was expensive.
The state is no longer immediately saved. Instead, it's just migrated

locally, and that migrated state will be persisted when the site

configuration is next saved to the database.
Saving the avatar settings is also less noisy. We no longer cause

multiple saves to the database and multiple siteconfig invalidations.

Instead, we set all the state up-front and then save it all at once.
Along with this, the defaults are now more reasonable when migrating

from an older version. It used to be that if Gravatars were disabled, we

wouldn't set any default/enabled services, meaning that if people wanted

to enable gravatars, they had a few fields to fill out. We now always

default a migrated configuration over to supplying Gravatars as the

default/enabled services, instead of clearing out the values. This helps

keep things consistent with the behavior used when saving the avatar

configuration in the form.

Unit tests pass.
Tested configuring avatars and toggling defaults.