Fix cagg trigger on compat schema layer

[fabriziomello]

The trigger continuous_agg_invalidation_trigger receive the hypertable
id as parameter as the following example:

Triggers:
    ts_cagg_invalidation_trigger AFTER INSERT OR DELETE OR UPDATE ON
       _timescaledb_internal._hyper_3_59_chunk
    FOR EACH ROW EXECUTE FUNCTION
       _timescaledb_functions.continuous_agg_invalidation_trigger('3')

The problem is in the compatibility layer using PL/pgSQL code there's no
way to passdown the parameter from the wrapper trigger function created
to the underlying trigger function in another schema.

To solve this we simple create a new function in the deprecated
_timescaledb_internal schema pointing to the function trigger and
inside the C code we emit the WARNING message if the function is called
from the deprecated schema.

Disable-check: force-changelog-file

[codecov]

Codecov Report

Merging #6163 (8702f4e) into main (b514d05) will decrease coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #6163      +/-   ##
==========================================
- Coverage   81.46%   81.41%   -0.06%     
==========================================
  Files         246      246              
  Lines       56974    56928      -46     
  Branches    12624    12605      -19     
==========================================
- Hits        46414    46347      -67     
+ Misses       8180     8171       -9     
- Partials     2380     2410      +30     

see 45 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[svenklemm]

Not a fan of this, this trigger should never be called through compat layer unless your database is already broken
I think we probably need a check that catalog and schema are in sync and bail if there is mismatch, this will just paper over deeper issue. I would prefer mapping to the C function directly in compat layer over adding more code to deal with this.

[fabriziomello]

Not a fan of this, this trigger should never be called through compat layer unless your database is already broken I think we probably need a check that catalog and schema are in sync and bail if there is mismatch, this will just paper over deeper issue. I would prefer mapping to the C function directly in compat layer over adding more code to deal with this.

We're mapping to C function directly already in this PR: https://github.com/timescale/timescaledb/pull/6163/files#diff-8943dabbdc6a8f1b136468c00599f91c6f615869a324b0de70b9c7614a77c9bfR191-R192

The only additional code is just to emit the WARNING message because the current form is wrong: https://github.com/timescale/timescaledb/blob/main/sql/compat.sql#L192-L199

[fabriziomello]

Chatting with @svenklemm we agreed that is better to don't add extra C code to emit the warning and just point the deprecated schema to the new one and adding regression test to make sure it is working. /cc @jnidzwetzki