Description
Case: a connection is acquired from a pool, then three fibers use it: one calls <connection object>:execute() and acquires a lock (let's consider a long request), another one perform other calls to :execute() and third one put the connection back to the pool.
Say, when the long request will be done, the third fiber will acquire the lock and put the connection to the pool. The old connection object will be marked as unusable, however the lock will not be released (see conn_put). The second fiber will be blocked infinitely.
Even if we'll release the lock in <pool object>:put() and the second fiber will wake up in :execute(), it will at the point after self.usable check and will try to execute a request. It will even succeed, but it looks as a side effect of #32.
It is maybe not quite correct usage, but we should handle it appropriately: wait for necessary events, give an error for an incorrect usage, don't leak resources and surely don't block a fiber infinitely.
It seems the similar problem with passed <connection object>.usable check may appears for a connection that is created with mysql.connect() w/o a pool if we'll try the similar case, but with <connection object>:close() instead of <pool object>:put().
NB: Add test cases for both described situations.