WIP Patch: Pgbench Serialization and deadlock errors

Hello, hackers!

This is the fourth version of the patch for pgbench. As in the previous
one, most of the changes were made thanks to the comments of Fabien
Coelho. Here I propose not to abort the client in pgbench in case of
various errors including unsuccessful meta commands. As in the previous
version, transactions with serialization and deadlock failures are
rolled back and retried until they end successfully or their number of
tries reaches maximum.

In details:
* Client's run is aborted only in case of a serious error, for example,
the connection with the backend was lost. Otherwise if the execution of
SQL or meta command fails, the client's run continues normally, except
that the current transaction block terminates if possible.
* If a failed transaction block cannot terminate in the current script,
its commands after the error as well as the commands of the following
scripts are processed as usual so you can get a lot of errors of type
"in failed SQL transaction" (when the current SQL transaction is aborted
and commands ignored until end of transaction block). In such cases you
can use separate statistics of these errors in all reports.

The main differences from the previous version:
* support for compound commands (as I understand, they are not properly
supported in the original version, since the execution status is
processed only for the first subcommand). Note that:
** not all compound commands that contain subcommands to start or end an
explicit transaction block can be retried. For example, you cannot use a
compound command to complete a failed transaction block before retrying.
Also if there're any subcommands before the explicit transaction block,
the latter cannot be retried from the very beginning.
** if you want to know which subcommands of compound SQL commands
failed, use the debug output.
* do not divide retries by type in all reports (you can get this
information from the debug output).
* (because of all of the above) option --debug-fails. If you want to
distinguish between failures or errors by type, or you want to know
which subcommands of compound SQL commands failed, use the the pgbench
debugging output created with the option --debug-fails or --debug. The
first option is recommended for this purpose because with the second
option the debugging output can be very large.
* tests for serialization/deadlock errors and retries use advisory locks
(as I wrote here [1] other more simple methods can sometimes fail); and
they became lighter (28 simple tests instead of 57, 8 runs of pgbench
instead of 17).

Other smaller differences from the previous version:
* receive information from the server whether we are in the transaction
block or not;
* naming fix (I will be very grateful if a native English speaker
comments on this): failures are errors if they cannot be retried;
* as usual, code cleanup; in particular, use states instead of the bool
variables to complete a failed transaction block.

Patch is attached. Any suggestions are welcome!

[1]
https://www.postgresql.org/message-id/e4c5e8cefa4a8e88f1273b0f1ee29e56%40postgrespro.ru

--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company