Motivation

To prepare for the large amount of voting we could see during the Board elections we should test how SecurePoll would handle concurrent voting. Here's what @tstarling wrote:

My main concern would be lock times in Auth::getVoter(). It originally had a real transaction wrapping > it but was converted to fake transactions (startAtomic/endAtomic) in 2016. It has a locking select which might lock the gap and prevent other users from authenticating. You could test it by setting up two browser windows logged in as different users, put a sleep(20) after the selectRow() in Auth::getVoter() to exaggerate the lock time, and then try to load the voting form in both browser windows. My guess is that you’ll see a 40s wait in one of the windows as one user waits for the other.
Or maybe there will be a deadlock error.

In an ideal scenario, no voter would see an error. We need to determine if this happens and if so we want to find possible mitigations.