EZP-23235: Improve eZOE's UrlObjectLink handling performance.

[joaoinacio]

JIRA: https://jira.ez.no/browse/EZP-23235

Problem: on content with many xml attributes, each with many links, there is the potential for hundreds or thousands of select/insert queries dealing with ezurl_object_link.

This replaces the 'N' selects with a single query, and calculates the difference of urls to insert vs existing ones. A transaction is also added, for performance reasons.

[gggeek]

About transaction usage:

1. they actually introduce CONTENTION. The db will most of the time be slower, not faster because of them.
2. never, EVER introduce transactions for anything else than data integrity. remember that ez supports nested transactions? a) if you introduce a nested transactions then roll it back, you will be rolling back the outher one => we had a bug with objects states doing that in the past b) if you introduce a nested transactions then commit, nothing happens, as only the other one will really commit

I imagine that in this code we will fall in case b above, as there will naturally be (should be?) a transaction wrapping the link-modification code

[gggeek]

PS: I checked the code. it seems that an outher transaction is indeed missing, and I surmise it should be there, in validateInput() :-(

[andrerom]

@gggeek there are several during editing, so do you agree with yourself to remove the added transaction here? @joaoinacio pov on this?

[joaoinacio]

The transaction isn't absolutely necessary for this PR, the single select query should already improve things somewhat. Still, it was added because:

• It is my understanding that bundling multiple inserts in a transaction will speed up the operation considerably (should be easily verifiable).
• Regarding data integrity, I see nothing wrong with "insert all url object links for an attribute" in a single operation.
• AFAIK eZDB supports and is able to handle nested transactions without any issues at this time (using a transaction counter).

@andrerom: My tests also show there is no ongoing transaction in this context (TransactionCounter = 0)