Order locking in controllers

The existing code for locking orders during requests wasn't doing anything.
A call to `lock` has to be made inside of a transaction to take effect, and there were no open transactions when we were calling it.
So, the existing code would unlock the order as soon as the line of code with ".lock" finished executing.  i.e., it was essentially a no-op.

This commit introduces the an OrderMutex table that uses the database to provide a mutex for operating on an order. We use this functionality at the controller level.

Ideally we'd have a clean entry point at the model level where we could use employ this mutex (or even a DB transaction), but at the moment we don't seem to have something like that.

Alternatively, we could wrap *everything* in the associated controller actions in one giant transaction, and create a lock on the associated order. However, this can affect DB performance and also means that any unhandled exceptions in these endpoints will roll back *all* database changes.  For example, you might charge a credit card, send out an "order complete" email, or send a message to your inventory management service, and then blow up on some subsequent (possibly trival) callback and everything in the DB would be rolled back, yet the credit card charge/emails/api calls would still have been sent.