Check if there is an allowance already before trying to make one.

[mfornet]

Suppose the following scenario happens:

1. User sets an allowance from the ERC20 token to the Locker in the frontend successfully
2. User tries to call lock on the Locker but it fails for any reason (timeout, low fees, or something else)

There is no way to recover from that state in case of failure in the second step, and frontend will ask to set a new allowance. Instead the contract should check first if such allowance exist, and not ask for it in case it exists and is enough. Right now users should submit a second transaction to set a new allowance which is suboptimal.

[paouvrard]

I cannot reproduce this. If approval succeded but lock fails, then retrying lock will not prompt for setting allowance again but retry the lock.
If the lock tx fails for any reason, the user is able to retry the lock tx.
If the lock tx fails because allowance is not enough to make the lock (user used it in another app):
It would be confusing to request approval again since approval is already marked as succeeded.
This is quite a rare scenario, so the process can be for the user to remove this transfer which was not started (not locked) and try a new one.

[mfornet]

Ok, if I find a new report about this, will inspect further and give you conditions to reproduce.