Fix XQuery Trigger chaining

[adamretter]

Previously it was possible to chain Java Triggers together into pipelines, e.g. the output created by one trigger, can fire events which cause another trigger to take that as input. However, this useful functionality was previously prohibited for XQuery Triggers. It was prohibited, as it was feared that XQuery users could create endless-loops between their Triggers, such behaviour ultimately results in StackOverflowError.

Documentation of behaviour is here - eXist-db/documentation#766.

This PR enables chaining for XQuery Triggers by incorporating an improved cyclic detection mechanism to prevent such StackOverflowError. When a cycle between XQuery Triggers is detected, the cycle is broken and a warning is logged to exist.log. When sensibly planned, users should be able to create XQuery Trigger pipelines without issue. If a mistake is made, they are protected as the cycle will be broken and a warning for them to correct the issue is logged.

Investigating and fixing this also revealed a few small other bugs along the way, for example CreateCollection events were fired during CopyCollection events; This PR corrects those also.

p.s. I have considered in detail the reports from Codacy and Sonarcloud, and I do not agree with their assessment. I think their suggestions would actually make the code harder for others to understand whilst yielding no technical gain.

[dizzzz]

how 'bad' are the missing triggers? it is not a new issue is it?

[line-o]

I consider this a feature. I would also like to see the bugs that sonar cloud complains about to be fixed.
At least this must be discussed in detail first.

[line-o]

I would like to see the issues reported in the analysis by sonar and codacy to be addressed.

[adamretter]

@line-o to try and allay your concerns, I have numbered each item from Codacy in a screenshot, and then explained each individually below.

1. This was previously as laid out in TriggerEvents.java. I preserved it as I believe it might be useful in future. I have now added a log statement to quiet Codacy (although I don't think it is really necessary).

2. NPathComplexity is not a good metric here. The code itself is simple, straight-forward and understandable by any novice programmer.

3. Combining the if statements together here would make the intention of the code less clear; the two predicates do not have an implicit relationship!

4. Same as (2).

5. Same as (2).

6. The unused Txn parameter is used in Elemental and FusionDB. It could be used in eXist-db in future if eXist-db chose to properly implement transactions. However, at present it allows a shared API to be used for users triggers across all 3 database systems - i.e. code reuse of EXPath packages. In addition changing it would break existing triggers that are deployed in the wild.

7. Same as (6).

8. I have removed the unused parameters apart from Txn (see 6).

9. Same as (2).

10. This advice in this context is wrong. Following it would change the behaviour and the code would no longer function correctly.

11. Same as (2).

12. This was the case before my changes. I have added a comment to quiet codacy.

13. Same as (12).

14. Same as (2).

15. As opposed to what? If your method is a distinct unit then it is a distinct unit!

16. This was how the method was named before my changes as this code was taken from the existing XQueryTriggerTest. I have now renamed it in both existing and new places to make Codacy quiet.

17. This was the case before my changes as this code was as taken from the existing XQueryTriggerTest. I have now adjusted it in both existing and new places to make Codacy quiet.

All-in-all no meaningful issues were discovered by Coadacy. I have appended the commit that quietens Codacy.

[adamretter]

@line-o Regards SonarCloud. There are 3 issues suggested, I believe 2 of them are existing issues from how eXist-db's Trigger API is structured. I believe they can safely be ignored in this context. The final issue about calling ThreadLocal.remove() I don't think would have been an issue in this context, however as it is easy to quieten SonarCloud here without changing the behaviour of the code I have addressed it as suggested by SonarCloud with an additional commit.

I hope all your concerns are now addressed.

[sonarcloud]

SonarCloud Quality Gate failed.   

2 Bugs
0 Vulnerabilities
0 Security Hotspots
50 Code Smells

46.7% Coverage
0.0% Duplication

all adressed.