autovacuum settings that can only be set in postgres.conf, reduce default work_mem to 64MB, plus small tweaks

 - hive: develop (74eb54442330ace71c37a43b464aee6b1bd4dae2)

previously only state providers shadow tables were excluded, what cause
problems when haf with installed context with registered tables was
updated.

Currently state providers creates tables in hafd schema. All tables in
hafd schemas are taken to db hash computation, but hashes for state
providers are computed differently, ans should not affect hafd hash
schema.

After many changes hash computed on databse could only be used to
check if  hfm can be updated to a given new version. The hash cannot be used
to check if the database schema for a given hfm version was modified,
becuase it does not take all haf elements for computation. It means
there is no need to have stored hash of the databas because it has no
usage, moreover it is misleading and could mask that the some parts of
 the schema was modified.

Warning: the change modifies hafd schema, what means that old hfm
versions cannot be updated to it.

Newer hash computation method is injected into the db with older hfm
version. Both naked new HAF db and old one use the same algorithm to
getting hash.

Now there is no need to extend list of hashed tables each time when
new table is added to schema hafd.

WARNING: previously people forget to  extend the list and there
are few tables which were not hashed. Because of this update from
previous version of HAF is impossible

There is no sense to pass schema parameter to hash db computation,
at the end there is a list of tables to take into computation and all of
them belongs to hafd schema.

 - hive: develop (a181ebfab21471951a369b138adb2f5003d7a642)

- repair an abandoned test for update and start it on CI
- fix for syntrax error during state provider update

 - hive: develop (015c4c0dc6b76d8b256363335609c5eadbcfaaeb)

This reverts commit e9fa365a

 - hive: develop (ef0e30e473fcc02ec5ca7f926fe1e3ca8301e02a)

Marcin authored 3 months ago and Dan Notestein committed 3 months ago

Previously, an application waited in app_next_iteration indefinitely for a moment when HAF reached the 'LIVE' stage what makes impossible to break with SIGINT and holds long-standing transaction. Now when HAF is before 'LIVE' then  app_next_iteration returns null block range after 500ms. Because no blocks range is returned application is forced to back ask again for blocks.

 - hive: develop (8d5912e639040fb8ec1452163d6bf166fd939d84)

Adjust functional tests, corrected genesis accounts, pow operation sets weight threshold to 1 instead of 0