Fix deadlock from taking db lock while holding authz lock in Authz()

[wallrj-cyberark]

Fixes #563.

Authz() held the authorization's write lock while it looked up the account, which takes the MemoryStore read lock. FindValidAuthorization takes the same locks in the opposite order. Once a writer such as AddAccount queues on the store lock, the whole store wedges. #563 has the details and a goroutine dump.

This change does both lookups before authz.Lock():

• The order's account ID. authz.Order is set when the authorization is created and never changes, so it is safe to read before taking the authz lock. Reading it first also removes the authz-then-order lock order, which is the reverse of Order.GetStatus().
• The requesting account, via validPOSTAsGET or getAcctByKey. Both branches did this lookup first anyway, so responses and error order do not change.

The authz lock now only covers reading and updating the authorization itself.

Testing

• With the stress client from Authz() holds the authz lock while taking the db lock, which can deadlock the whole store #563, main hung within 1 second in each of 3 runs. With this change it ran for 10 minutes and 264,962 operations without hanging.
• go test -race ./... passes. The wfe package has no tests, so the stress client is the only test of this path.

[with Claude]

[wallrj-cyberark]

Self-review: one note on why the order is read without the authz lock, and one place I left alone.