feat: add wal2json container image

[solidDoWant]

Adds a new immutable extension image for wal2json, the JSON output plugin for PostgreSQL logical decoding. The image is built for PostgreSQL 18 on Debian bookworm and trixie, packaged from the PGDG postgresql-18-wal2json package (2.6-3).

Since wal2json is a logical decoding output plugin (no SQL extension, no .control file), create_extension is false and the Chainsaw suite verifies the plugin by creating a logical replication slot with wal2json and asserting the slot becomes active.

Includes CODEOWNERS entry, maintainer metadata, and a top-level README listing.

Closes #77

Assisted-by: Claude Opus 4.7

[reyvonger]

bump

[gnom4ik]

bump

[gbartolini]

Successfully ran:

task e2e:test:full TARGET=wal2json

[gbartolini]

You basically commit to maintaining this extension image, including future updates. And if you don't, we, the maintainers, reserve the right to remove the extension from this project. We normally ask this when somebody submits an extension via the issue tracker (see #77 - theoretically we should have closed that ticket and you should have opened a new one - or you comment on that ticket saying that you are available to take over).

I hope it is clearer now. It is also briefly explained in the contributing guidelines for a new extension.

Let me know if you are happy to go.

[gbartolini]

Awesome, added you as CODEOWNER.

[GabriFedi97]

I guess enableSuperuserAccess: true was added because creating replication slots is only allowed for roles having the REPLICATION attribute.

We could just grant the replication attribute to the default user by using the managed roles, so we can avoid enabling the superuser:

Suggested change

	enableSuperuserAccess: true
	managed:
	roles:
	- name: app
	ensure: present
	login: true
	replication: true

[gbartolini]

I considered that, but I'm not certain which option is cleaner since we typically don't want to grant replication permissions to the standard app user, except for convenience. However, this approach prevents the assignment of superuser access and might fall into the convenience category. :)

If you'd like to propose this change, @GabriFedi97, I will approve it. Thank you!

[GabriFedi97]

I think that makes more explicit and clear which additional privilege is required, rather than granting all of them via the superuser. This is just a testing environment though, so I'm not too opinionated either.