Fix infinite recursion for schema_list_extensions() catalog query

[kbarber]

Fixes: #749

This PR: #702 introduced important ordering for extension installation that took into account relationships between extension configuration tables.

The new query executed by schema_list_extensions() seems to have an infinite loop. You can reproduce this by running a pgcopydb clone with the follow tables:

create table one (id int, two_id int);
create table two (id int, one_id int, three_id int);
create table three (id int);
alter table one add constraint one_pk primary key (id);
alter table two add constraint two_pk primary key (id);
alter table three add constraint three_pk primary key (id);
alter table one add constraint one_two_fk foreign key (two_id) references two(id);
alter table two add constraint two_one_fk foreign key (one_id) references one(id);
alter table two add constraint two_three_fk foreign key (three_id) references three(id);

This patch attempts to remove the loop by adding cycle detection as documented as a pattern here: https://www.postgresql.org/docs/current/queries-with.html#QUERIES-WITH-CYCLE it also adds the above tables & FK creations to extensions/copydb.sh to test for regression in the future.

[kbarber]

@JamesGuthrie if you have any strong feelings about this fix, or a better idea please let me know :-). I'm worried the cyclic detection might affect the depth, but I think the new change probably corrects the depth now its not infinite.

I was thinking of adding the tests that James described here: #701 to avoid regression since its a complex query. Looks like it needs the TimescaleDB extension.

[dimitri]

Thanks for the fix! I think we could maybe improve on the spelling of the test case, so while I could merge as-is, if you think my proposal is an improvement would you be up for another revision before merge?

[dimitri]

Can we inline the pkey and fkey definitions into the CREATE TABLE statements? I think it's easier to read. It needs be, let's just add another SQL file to that test unit (such as ddl.sql as found in other units) to have more flexibility in the SQL syntax/layout.

[kbarber]

@dimitri 'twas a fun problem, let me know if you need anything else on this one.