Fix visited status creation race condition

**The problem:** Our uniqueness validations for visited statuses weren't safe in a concurrent environment, and we were running into situations where a single user/thread pair had multiple statuses. This broke certain assumptions on other parts of the site. The problem seems to arise primarily in our webhooks controller handling open tracking – if someone manages to load the tracking image in quick succession, Mailgun will fire off a bunch of opened events that can lead to high concurrency while creating visited statuses.

**The fix:** Use our existing distributed lock to acquire a lock for a single user/thread/pair when creating and updating new visited statuses. This ensures that a thread is able to create the first visited status before concurrent threads attempt the same.

The included test is not 100% reliable. It never seems to fail incorrectly, but without the distributed lock in place the test will still succeed some amount of the time. I'm not entirely sure how to make the test better, but I don't think we should block on deploying this.