The following error occurs when using `imagemagickBig`:

    $ ./result/bin/identify sample.jp2
    [1]    699089 IOT instruction (core dumped)  ./result/bin/identify sample.jp2

When looking at the call-trace it seems as if certain symbols, e.g.
`opj_malloc` are mixed up:

    #8  0x00007f78c79ad2f5 in MagickSignalHandler.cold () from /nix/store/bqy80qiw6czqh7vsmmmivwdswp9zzjgl-imagemagick-7.1.0-29/lib/libMagickCore-7.Q16HDRI.so.10
    #9  <signal handler called>
    #10 0x00007f78c5a6095f in opj_malloc () from /nix/store/wg6ly83k1k1fjiygiv1jr7li3p6dwsvq-ghostscript-with-X-9.55.0/lib/libgs.so.9
    #11 0x00007f78c5a60981 in opj_calloc () from /nix/store/wg6ly83k1k1fjiygiv1jr7li3p6dwsvq-ghostscript-with-X-9.55.0/lib/libgs.so.9
    #12 0x00007f78c4f48e24 in opj_create_decompress () from /nix/store/qwalb0kjz1p9c4j48qkk6ql47ds2lnhh-openjpeg-2.4.0/lib/libopenjp2.so.7

The `opj_create_decompress()` is called from the `openjpeg`-integration
of `imagemagick` and thus shouldn't affect `ghostscript` at all.
However, `ghostscript` (`libgs.so` to be precise) also exposes e.g.
`opj_malloc`:

    $ objdump -t /nix/store/wg6ly83k1k1fjiygiv1jr7li3p6dwsvq-ghostscript-with-X-9.55.0/lib/libgs.so.9.55|grep opj_malloc
    0000000000205940 g     F .text	000000000000002b              opj_malloc

Because of that, two incompatible symbols are used in the same process
and thus the `identify`-call breaks because the wrong one is used. To
work around that I decided to use the system-wide openjpeg instead.
I'm not sure why `libgs.so` wants to expose these symbols anyways, but
with that workaround the problem is solved.

Even though it's mentioned that ghostscript's openjpeg is heavily
patched, I think that this is somewhat outdated or at least irrelevant
considering that both ArchLinux[1] and Fedora[2] use the system-wide
`openjpeg` instead.

[1] https://github.com/archlinux/svntogit-packages/blob/bafcb5473b59d5386dd110d1cb249372dce9ea6c/trunk/PKGBUILD#L50
[2] https://src.fedoraproject.org/rpms/ghostscript/blob/e4eec13ab6ace2bad64b740d352964bbf61d1aa7/f/ghostscript.spec#_245

fluent-bit 3.2.7, 3.2.8 and 3.2.9 are segfaulting when
used in combination with the systemd input. Lets
revert to 3.2.6 for now.

Upstream bug: fluent/fluent-bit#10139

Note that fluent-bit-3.2.7 fixes two high CVEs which we are now
reintroducing. However they are only exploitable if you are
using the OpenTelemetry input or the Prometheus Remote Write input.

OpenTelemetry input: [CVE-2024-50609](https://nvd.nist.gov/vuln/detail/CVE-2024-50609)
Prometheus Remote Write input: [CVE-2024-50608](https://nvd.nist.gov/vuln/detail/CVE-2024-50608)

The problem is as follows:

3.2.7 started vendoring a copy of `libzstd` in tree and statically
linking against it. Also, the fluent-bit binary exports the symbols
of static libraries it links against.

This is a problem because `libzstd` gets `dlopen()`ed by `libsystemd`
when enumerating the journal (as journal logs are zstd compressed). and `libzstd` in Nixpkgs is built
with `-DZSTD_LEGACY_SUPPORT=0` which causes `struct ZSTD_DCtx` to be 16
bytes smaller than without this flag https://github.com/facebook/zstd/blob/dev/lib/decompress/zstd_decompress_internal.h#L183-L187

`libsystemd` calls [`sym_ZSTD_createDCtx()`](https://github.com/systemd/systemd/blob/1e79a2923364b65fc9f347884dd5b9b2087f6e32/src/basic/compress.c#L480)
which calls the function pointer returned by `dlsym()` which is calling into
the `libzstd` that comes with `nixpkgs` and thus allocates a struct that is 16 bytes smaller.

Later then `sym_ZSTD_freeDCtx()` is called. However because fluent-bit
has `zstd` in its global symbol table, any functions that `sym_ZSTD_freeDCtx()`
calls will be calls to the functions in the vendored fluent-bit version of the library
which expects the larger struct. This then causes enough heap corruption to cause
a segfault.

E.g. the subsequent calls to `ZSTD_clearDict(dctx)` and `ZSTD_customFree(dctx->inBuff)`
in https://github.com/facebook/zstd/blob/dev/lib/decompress/zstd_decompress.c#L324
will be working on a struct that is 16 bytes smaller than the one that was allocated
by `libsystemd` and will cause a segfault at some point and thus are probably modifying
pieces of memory that they shouldn't

	(gdb) bt
	#0  0x00007f10e7e9916c in __pthread_kill_implementation () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6
	#1  0x00007f10e7e40e86 in raise () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6
	#2  0x00007f10e7e2893a in abort () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6
	#3  0x000000000046a938 in flb_signal_handler ()
	#4  <signal handler called>
	#5  0x00007f10e7ea42b7 in unlink_chunk.isra () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6
	#6  0x00007f10e7ea45cd in _int_free_create_chunk () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6
	#7  0x00007f10e7ea5a1c in _int_free_merge_chunk () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6
	#8  0x00007f10e7ea5dc9 in _int_free () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6
	#9  0x00007f10e7ea8613 in free () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6
	#10 0x00007f10e80ad3b5 in ZSTD_freeDCtx () from /nix/store/wy0slah6yvchgra8nhp6vgrqa6ay72cq-zstd-1.5.6/lib/libzstd.so.1
	#11 0x00007f10e8c90f6b in decompress_blob_zstd () from /nix/store/b2cfj7yk3wfg1jdwjzim7306hvsc5gnl-systemd-257.3/lib/libsystemd.so.0
	#12 0x00007f10e8bf0efe in journal_file_data_payload () from /nix/store/b2cfj7yk3wfg1jdwjzim7306hvsc5gnl-systemd-257.3/lib/libsystemd.so.0
	#13 0x00007f10e8c00f74 in sd_journal_enumerate_data () from /nix/store/b2cfj7yk3wfg1jdwjzim7306hvsc5gnl-systemd-257.3/lib/libsystemd.so.0
	#14 0x00000000004eae2f in in_systemd_collect ()
	#15 0x00000000004eb5a0 in in_systemd_collect_archive ()
	#16 0x000000000047aa18 in flb_input_collector_fd ()
	#17 0x0000000000495223 in flb_engine_start ()
	#18 0x000000000046f304 in flb_lib_worker ()
	#19 0x00007f10e7e972e3 in start_thread () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6
	#20 0x00007f10e7f1b2fc in __clone3 () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6

Reverts 7310ab3
Reverts 4fbc6cf