Batching of postgres updates during recon

[andrewgdotcom]

Heavy recon sessions that involve lots of key updates cause postgres to spike to 100% CPU usage and are two orders of magnitude slower than restore from dump. This is most likely due to the overhead of single-update transactions, and could be mitigated by batching updates and using bulk submission (same as for restore). We could then treat each hashquery update as a single batch of (up to) 100 keys at a time.

The major disadvantage would be that backoff+retry would become much more likely, and much heavier to manage.