Fix Leaking Flocks

[karnatmugo]

Context Of Problem

Lock Cleanup

When apache uses mod_php to serve a request, then any locks left open by PHP calls to flock are closed automatically when the request finishes.
This means that under normal use, buggy eZ PHP code that leaves dangling locks is harmless, as these are cleaned up.

However, for long running processes under gearman, this does not happen and dangling locks become dangerous.

eZ has a bug such that if object view cache is prepared using a template which sets cache_ttl to 0 will leave a dangling lock on the cache mutex.
A template doing this will have something like the following sample in it

{set-block scope=global variable=cache_ttl}0{/set-block}

This is in ezpublish_legacy/kernel/classes/clusterfilehandlers/ezfsfilehandler.php, near the end

        // Check if we are allowed to store the data, if not just return the result
        if ( !$store )
        {
            $this->abortCacheGeneration();
            return $result;
        }

        // Store content locally
        $this->storeContents( $binaryData, $scope, $datatype, true );

        $this->_freeExclusiveLock( 'storeCache' );

Here, if the cache ttl is set to zero, $store will be false, and the method will exit before it calls $this->_freeExclusiveLock.
If a lock has been taken, it will be leaked under gearman.  Under httpd mod_php or a command line php script, it will be cleaned at the end of the run.

[karnatmugo]

@brookinsconsulting This attempts to address your comment on #1468

[sonarqubecloud]

SonarCloud Quality Gate failed.   

61 Bugs
4 Vulnerabilities
4 Security Hotspots
540 Code Smells

No Coverage information
33.8% Duplication

Catch issues before they fail your Quality Gate with our IDE extension SonarLint