Ensure common static assets paths are skipping sessions

[themightychris]

In newrelic log data, we see that /img/**/*.png and /webapps/*/resources/** requests are loading the sessions table and being slowed down substantially when the database is thrashing. These assets are all public though with no access restrictions and should be in the Site::$skipSessionPaths list.

One potential complication here though is that /webapps/* ARE subject to access control, and the current implementation of Site::$skipSessionPaths is only capable of matching path prefixes—so it may need to be enhanced to support glob patterns

[themightychris]

Did some initial investigation into this:

• quarry02 is running emergence 1.0.8, the 1.0.x line of releases is generally deprecated and only used for native installations on older Ubuntu environments. The newer 1.1.x line is for Docker-based deployments where newer environmental dependencies can be relied upon
• The 1.0.x line currently only features exact string matching for $skipSessionPaths
• $skipSessionPaths was upgraded to match prefixes instead of entire strings in EmergencePlatform/php-core and that was backported to the legacy kernel 1.1.x line
• gatekeeper seems to be why prefix support was added and is likely the only place relying on the added support currently
• strpos prefix matching benchmarks the fastest, fnmatch takes about twice as long, and preg_match takes about 3 times as long—but they're all negligible
• fnmatch has the advantage that all current exact string matching configuration values would keep working, and Gatekeeper's prefix values would only need to be upgraded to end in /*
• moving to preg_match would be a bit more complicated, as there wouldn't be any good way to know whether existing values are patterns or exact strings

The best options seems to be to upgrade current php-core and legacy kernel releases to use fnmatch and then coordinate a new release or the next build of Gatekeeper to pair the new php-core version with upgraded skipSessionPaths config values

Doing a new 1.0.x release and then upgrading quarry02 would be kind of risky though, and we want to migrate that host to a modern docker-based one ASAP though, so it might make the most sense to get this prepared and then defer deployment until we migrate quarry02 to a new machine.

In the meantime, we might hotpatch quarry02—there's basically zero risk we're going to accidentally upgrade it