Fix EZP-26907: avoid 'mysql has gone away' errors

[gggeek]

No description provided.

[gggeek]

Side note: it might be that this PR works for the 90% scenario, ie. eZP connected to a single DB, but not for the case where one eZP install uses different db connections for different siteaccesses.
I am looking into making that 2nd case work as well, if possible in a generic way.

[gggeek]

Fixed the problem with the case where multiple doctrine db connections are declared. Ready for review.

[gggeek]

ping

[gggeek]

Anyone up for review ?

[pkamps]

It's a common problem for long running scripts. I wonder if the kernel would be able to handle it in a better way (and not just through a 'Server has gone away' error).

[gggeek]

@pkamps it is true that this is a problem as well for some long-running scripts, however it is a hard problem to fix for the general case, as it is pretty much related to mysql version, mysql configuration (which can sit in 3 places: mysql server, mysql client, php.ini) and the activity of the app (how frequently it executes queries).
And we can not just blindly re-execute failed queries, because they might have been part of transactions that got rolled back etc...

On the other hand this is a known error bound to happen almost all of the time, even though the indexation script does do frequent db queries, for the reason that the script does use the 'fork' system call, and it does not handle properly the passing around of the db-connection file descriptor. As far as I am aware, it is the only legacy script that does use fork.
So it makes sense to have a specific fix.