This is a follow-up to:

• Implement Compression Streams API for URL Metrics JSON Compression #1905
• Fix triggering post update actions after storing a URL Metric and refactor REST API endpoint logic into class #1865

Most recently, it now addresses #1928 by disabling gzip compression by default since doing so at the pagehide event results in errors in Safari and the detect() function's execution being aborted at the point that compression is performed.

This PR also does the following, which were the original scope of this PR:

• Use Content-Encoding header instead of Content-Type to indicate gzip compression
• Use fetch() with keepalive instead of navigator.sendBeacon()
• Add a od_gzip_url_metric_store_request_payloads filter (which now is false by default)

In the former, gzip compression was introduced for the URL Metric JSON data being submitted. This drastically reduces the payload size which is important because there is a 64 KiB limit for beacons. However, when I look at the request in DevTools I see the following:

POST /wp-json/optimization-detective/v1/url-metrics:store?_wpnonce=f5ee4cdd67&slug=d751713988987e9331980363e24189ce&current_etag=5dff21b3549bbe22019407c953755389&cache_purge_post_id=484&hmac=e186efbbb61f1cb879117236ccc6fc95 HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 1592
Content-Type: application/gzip

Notice how the request payload is displayed in binary in DevTools. This got me to thinking whether using the application/gzip was correct. At first I thought maybe application/json+gzip would be a solution, but that isn't standard. Then I remembered the Content-Encoding request header. It allows for the Content-Type to remain application/json (which seems important!) but then to also send a Content-Encoding: gzip when the request body is compressed with gzip.

Nevertheless, it is not possible to set the Content-Encoding header when using navigator.sendBeacon() however. But, there is a new equivalent to navigator.sendBeacon() by using fetch() with the keepalive: true option. This was previously discovered in #1311 (comment). This is Baseline Widely Available (caniuse). And fetch() with keepalive does allow you to include arbitrary request headers (as well as use HTTP methods other than POST). Additionally, according to umami-software/umami#1160, navigator.sendBeacon() is blocked by ad blockers like uBlock Origin, so switching to fetch() with keepalive could result in additional URL Metrics being collected.

I conferred with Gemini which confirmed that using Content-Type: application/json with Content-Encoding: gzip is the correct and standard approach: https://g.co/gemini/share/ba550d36273e

With all this said, Chrome DevTools still doesn't pretty-print the gzip-encoded JSON. But this seems like a limitation with DevTools.

Nevertheless, if it so happens that the server is unable to accept gzip-compressed JSON request bodies, or if during development you want to be able to see the uncompressed data being sent, this PR introduces od_gzip_url_metric_store_request_payloads filter which can prevent gzip compression from being used, regardless of whether gzdecode() is available in PHP. This is false by default since.

This PR also updates the detection script to log out the compression percentage when gzip is being used. Lastly, it moves the OD_REST_URL_Metrics_Store_Endpoint::decompress_rest_request_body() method to be a separate od_decompress_rest_request_body() function per #1865 (comment).