[Bug Report + Patch] File descriptor leak when io_method=io_uring

Hi,

Thanks for your comments. Let me address them to the best of my ability.

> I believe this needs some more attention as this ring fd leak is going to
> cause harder outages in larger shops (single crash is going to cause leak,
> but then double allocation of the rings due to ulimit causing errno/EMFILE)

This is actually how we encountered the bug in the first place, except we were
hitting `ulimit -l` since our servers have a very high `ulimit -n`:

```
FATAL: could not setup io_uring queue: Cannot allocate memory
LOG: database system is shut down
```

> v2 LGTM to me, but does not apply due to AioShmemInit() taking some
> args now and there is this confusion (v2 preferred and less prefered v3),
> so maybe v4 should be sent to avoid confusion (v2 just rebased)?

I seem to have created some confusion with my versions, which I apologise
for. Let me try to correct that:
- v1: My initial naive implementation which adds the on_shmem_exit()
callback directly in pgaio_uring_shmem_init().
- v2: Adds the shmem_cleanup callback to IoMethodOps.
- v3: Rebases v2 because of the new API introduced in 58a1573.

So the rebase you ask for is v3, sent on the 17th of April. To settle the
numbering confusion I have attached v4, which I describe below.

> Could adding shmem_cleanup to IoMethodOps introduce an ABI break?
> If so, the v1 approach seems preferable, at least for a backpatch to v18?

Since aio_internal.h is installed as a server header and the new field is
added in the middle of the struct, v3 introduces an ABI break with PG 18
if backpatched.

As PG 18 is affected, I think this is worth backpatching. However, the new
shmem allocation functions aren't in PG 18, so the backpatch would need to
be v2-shaped and move `shmem_cleanup` to the end of the struct.

Since the backpatch needs a separate patch either way, master isn't constrained
here, so v4 keeps `shmem_cleanup` next to `shmem_callbacks`. I am happy to
send a backpatchable version if there is agreement on backpatching.

Alternatively, if maintaining a separate backpatch variant is undesirable,
v1 is still available. It doesn't change the `IoMethodOps` struct at all,
so the ABI question disappears.

> Just some nit: shouldn't we return / Assert() if not IsUnderPostmaster in
> pgaio_uring_shmem_cleanup()?

v4 adds an `Assert(!IsUnderPostmaster)` at the start of `pgaio_uring_shmem_cleanup`.

> The CF entry is currently Ready for Committer, but the latest review
> prefers v2 while noting that it no longer applies after the
> AioShmemInit() change. It also leaves the IsUnderPostmaster check open.
>
> Could you post a single vNext with the intended design, rebased to the
> current API, and address that check? I have moved the entry to Waiting
> on Author for now.

v4 addresses all these items. I have moved the CF entry to "Needs review".

Thanks again for all your feedback.

Lucas.