PKG-895: Allow citus and timescaledb to compile

[dutow]

Let's talk about this patch again!

Same as before, only for the PSP18 branch for now, 17 needs the same changes of course.

The pg_tde repo will need a matching

allow_upstream_smgr_api = false;

change if we go with this patch as-is.

This commit reintroduces the old method signatures of some methods we changed to support pg_tde. The changed method signatures still exists with a "2" suffix, and all internal code calls the "2" methods.

The reintroduced original methods also check a global flag which can disable them - if this happens, they report a FATAL error instead. This variable is activated by pg_tde, which means that if something tries to use these while pg_tde is loaded, and with that, possibly ignores its file tracking mechanism, it reports an error.

In practice this means that timescaledb, or the columnar storage in citus won't work if pg_tde is loaded in the shared_preload_libraries, but they can be used with our distribution without pg_tde enabled.

Also verified that both citus and timescaledb do compile with these changes, and their basic test suite can be run againts our fork.

[jeltz]

Apaart from some naming and style feedback I have one big question:

It feels a bit scary that we error out (now with FATAL but I think it could just be ERROR, not that that would help that much) not when Timescale or Citus are loaded but instead later when something uses them. But I can't really think of a better solution. We could of course have pg_tde warn if we see them loaded but we do not want to prevent them for using their own patched Citus so we can jsut warn which people probably will miss.

Maybe this is the least bad, hmm.

[dutow]

This also does not follow PG's C style.

Maybe we should add back the code formatting CI task to this repo?

[jeltz]

I like the patch but maybe we should have a discussion on slack about my concern about ERRORing out in these code paths. Can it cause some bad harm to users or is it good enough?

[jeltz]

I think we would need to also bump the percona_api_version, right?