Autonomous transactions 2023, WIP

Hello. I'm working on the support of autonomous transactions in Postgres.
Could you please make a preliminary review and give advices (see section
#TODO)

# Patch
v0001-Autonomous-transactions.patch

# Introduction
This patch implements Autonomous Transactions for PL/pgSQL.
Autonomous transaction is a transaction that can be succesfully commited
even if base transaction is rolled back. Common use cases:
logging/auditing/tracking progress in tables, so that information about
the execution attempt is preserved even when the main transaction is
rolled back — for example, due to an error.

# Glossary
Session - entity that groups multiple related SQL commands into a single
transaction.
Main session (backend, foreground session) - session through which the
user interacts.
Main transaction (parent) - transaction that runs in the main session.
Autonomous session - session that performs an offline transaction. It
starts from the main session.
Autonomous transaction - independent transaction that runs inside an
autonomous session.
Autonomous function - function with the pragma AUTONOMOUS_TRANSACTION.
When it is executed, an autonomous session is created in it.
Background worker - background process that performs some actions in the
background, without the user's participation.
dsm - dynamic shared memory.
shm_mq - shared memory message queue.

# Internals
This patch introduces a "pragma AUTONOMOUS_TRANSACTION" to functions.
When one such function is executed all (at the current time not all,
WIP) statements from it are executed in an autonomous session.

* Example *
*SQL-request:*

```sql
CREATE TABLE tbl (a int);
CREATE OR REPLACE FUNCTION func() RETURNS void
LANGUAGE plpgsql
AS $$
DECLARE
  PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
  INSERT INTO tbl VALUES (1);
END;
$$;

START TRANSACTION;
SELECT func();
ROLLBACK;

SELECT * FROM tbl;

DROP FUNCTION func;
DROP TABLE tbl;
```

*Output:*

```bash
 a
---
 1
(1 row)
```

For each backend the patch lazily creates a pool of autonomous sessions.
When backend calls autonomous function, backend takes one autonomous
session from this pool and sends there function's statements for
execution. When execution is finished backend returns session to pool.
Lazily means that pool is created only when first autonomous session is
needed.
Backend and autonomous session communicate with the help of Postgres
client-server protocol. Messages are sent through dynamic shared memory.
Execution of backend and autonomous session is synchronous: autonomous
session waits for messages from backendand backend waits for messages
from autonomous session.
Autonomous session uses Background workers internally. As it's a
separate process, it contains caches, etc. In order to prevent infinite
grow of resources usage we reset all caches by timeout using restart of
autonomous sessions. This timeout is set by guc setting
autonomous_session_lifetime.
Source code contains more detailed comments.

# Alternatives
At the current time for this functionality may be uses extensions:
dblink and pg_background. But they have shortcomings:
    1) not in the Postgres core, they are extensions
    2) lower performance. Each call creates new process that is
destroyed immediately after transaction is finished.

# TODO
Could you please give advices how implement public pool shared between
all backends?
1) Support execution of remaining statements in autonomous sessions.
2) Public pool shared between all backends. At the current time for each
backend private pool is created.

# Tests
Implementation contains many regression tests of varying complexity,
which check supported features.

# Platform
This patch was checkouted from tag 15.4. This is WIP. I've developed in
Linux, code doesn't contain platfrom-specific code, only Postgres
internal data structures and functions.

# Documentation
Regression tests contain many examples
* Describe the effect your patch has on performance, if any.
It adds a new feature and increase performance compared to dblink and
pg_background

# History
## 1st feature requests and discussions in pgsql-hackers (without code)
1) 2008
https://www.postgresql.org/message-id/flat/1A6E6D554222284AB25ABE3229A9276271549A%40nrtexcus702.int.asurion.com
2) 2010
https://www.postgresql.org/message-id/flat/AANLkTi%3DuogmYxLKWmUfFSg-Ki2bejsQiO2g5GTMxvdW2%40mail.gmail.com
3) 2011
https://www.postgresql.org/message-id/flat/1303399444.9126.8.camel%40vanquo.pezone.net
4) 2011
https://wiki.postgresql.org/wiki/Autonomous_subtransactions
5) 2011
https://www.postgresql.org/message-id/flat/20111218082812.GA14355%40leggeri.gi.lan
https://wiki.postgresql.org/wiki/Autonomous_subtransactions
## Implementaion
1) 2014, Rajeev Rastogi, implementation based on subtransactions
https://www.postgresql.org/message-id/flat/BF2827DCCE55594C8D7A8F7FFD3AB7713DDDEF59%40SZXEML508-MBX.china.huawei.com
2) 2015, Rajeev Rastogi, new theme, continues discussion about semantics
and syntax of autonomous transactions
https://www.postgresql.org/message-id/flat/BF2827DCCE55594C8D7A8F7FFD3AB7715990499A%40szxeml521-mbs.china.huawei.com
3) 2016, Peter Eisentraut, implementation based on background workers
https://www.postgresql.org/message-id/flat/659a2fce-b6ee-06de-05c0-c8ed6a01979e%402ndquadrant.com

# Summary
* Add pragma AUTONOMOUS_TRANSACTION in the functions. When function
contains this pragma, the it's executed autonomously
* Background workers are used to run autonomous sessions.
* Synchronous execution between backend and autonomous session
* Postgres Client-Server Protocol is used to communicate between them
* Pool of autonomous sessions. Pool is created lazily.
* Infinite nested calls of autonomous functions are allowed. Limited
only by computer resources.
* If another 2nd autonomous function is called in the 1st autonomous
function, the 2nd is executed at the beginning, and then the 1st
continues execution.

--
Best wishes,
Ivan Kush
Tantor Labs LLC