Excessive calls to variable_set

Problem/Motivation

I am using the Opigno LMS distribution and there are excessive calls to variable_set comming from this module, namely H5PDrupal::setUnsupportedLibraries method. This is invoked from H5PCore::validateLibrarySupport. For low scale sites this might be ok, but variable_set is a heavy functionality that should be avoided at all times during normal run-time, as it invalidates variables cache item.

Problem 2:
Also there seems to be a logical issue, when all the libraries are supported, then the result will always be null, so H5PCore::validateLibrarySupport full body is executed always, always setting NULL in the end.

Proposed resolution

There are 3 issues that I can see at the moment for the first problem:
1.1. The calls to H5PDrupal::setUnsupportedLibraries are invoked within the loop on every iteration, instead of ones the loop is over.
1.2. The implementation of H5PDrupal::setUnsupportedLibraries can spare the DB write call altogether with a pre-preemptive check. Is there a change in the value and only write then.
1.3. Refactor the whole thing to use the cache API and avoid using variables for it altogether.

In this case:
Point 1.1 will reduce the writes from 10-15 in my case to 1 in the end of the loop.
Point 1.2 will reduce the writes from 1 to 0 if there is no change in the incoming value, compared to the one in DB.

Point 1.3 - This whole functionality sounds more like a cache than configuration, so it sounds more reasonable to have this data stored in cache API instead of variables. This will be the best approach, as variables cache item is part of the critical path. It should be as small as possible. This needs discussion and I do not know this module good enough to propose such modifications at the moment.

Problem 2:
This should be fixed relatively easy by setting empty array as a value in the end instead of NULL. This way it will not be null and the code will know that there are no invalid libraries added in the project. The problem here comes from invalidating this data at some point, when code is changed (library updated). This can be solved by having implemented point 1.3 (cache API) using libraries bin (maybe). So when you update a library and clear libraries cache, this will trigger re-validation of the libraries, but not on all the requests in the meantime.

Remaining tasks

Discussion, patch, review, RTBC, commit.

User interface changes

None.

API changes

None.
This is a change in implementation detail.

Data model changes

None.