docker_entrypoint.sh has started hivemind as subprocess and did not pass
signals to it

https://stackoverflow.com/questions/76462990/python-docker-sigterm-not-being-fired-on-container-stop

Hivemind owner role must be explicitly specified while creating a database objects (since whole application install process is executed by haf_admin role)

Implemented new hivemind working mode: build_schema to separate Hivemind installation step from block processing

Objects being owned by hivemind role can't be reassigned to postgres, since it prevents execution of successfull setup next time (since already existing objects are owned by sysadm)

--postgres-url option should be passed directly to the docker entrypoint, because it performs its dedicated processing.

docker_entrypoint.sh extended by support of standard `install_app`, `uninstall_app` subcommands. Also added standardized alias `--postgres-url` to specify a database connection.

ROLLBACK needs to set transactions as finished to allow
start new transaction by db adapter.

It fixes random crash during breaking with SIG_INT

it happens randomly that some connections are not closed immediatly after executing close() method from sqlalchemy

#207

Code which was used to handle finalization of massive sync after
restart makes commit, and then blocks were processed in other
transaction than call of hive.app_next_block

When live sync (aka. SINGLE) is being breaking then sitaution
when no block is returned to process may occure, and then
ROLLBACK has to be issued to revert all not already committed changes.

We are controlling livetime of all pq connections opened by the sync
code, so we don't need connection pooling. Moreover we had random
issues with closing contections, which were not effectively closed
after close() returns.
#207

Previously PayoutStatsView and Mentions were refreshed during live sync in separated
threads, but it was illegal since they use the same connection as the
main thread with app_next_block call. It is also impossible to start these
operations safty in separated threads on separate db connections,
becuase it will require to start new transactions for each connections,
and then commit them separatly, regardles of the results of queries in
the main and other  threads.

Previously first app_next_block after reaching the limit was commited,
what moves hivemind context to the next block after the limit without
processing it

Updated HAF submodule to get fixes related to DROP function statements, preventing function definition upgrade

Supplemented definition of helper script due to changed interface of `hive.wait_for_ready_instance` function.