Correct hadnling of SQLite's BUSY

Currently we set BUSY timeout and use it retry acquiring lock on database. But according to docs this method is not bulletproof:

> The presence of a busy handler does not guarantee that it will be invoked when there is lock contention. If SQLite determines that invoking the busy handler could result in a deadlock, it will go ahead and return SQLITE_BUSY to the application instead of invoking the busy handler. Consider a scenario where one process is holding a read lock that it is trying to promote to a reserved lock and a second process is holding a reserved lock that it is trying to promote to an exclusive lock. The first process cannot proceed because it is blocked by the second and the second process cannot proceed because it is blocked by the first. If both processes invoke the busy handlers, neither will make any progress. Therefore, SQLite returns SQLITE_BUSY for the first process, hoping that this will induce the first process to release its read lock and allow the second process to proceed.

We need to determine how BUSY should be handled.

https://www.sqlite.org/c3ref/busy_timeout.html
https://www.sqlite.org/c3ref/busy_handler.html