Add metrics for the checksums of the HTTP body

[silkeh]

Add metrics to monitor the integrity of an HTTP resource. These are configured using:

• fail_if_body_not_matches_hash configures hash-based probe failures.
• hash_algorithm (sha256 by default) configures the hash used.
• export_hash enables exporting the hashed body as a label.

This results in the following new metrics:

• probe_http_content_checksum contains the CRC32 of the page as a value. This is not cryptographically secure, but should work sufficiently well for monitoring changes in normal situations.
• probe_http_content_hash contains a configurable hash of the page in a label. This is cryptographically secure, but may lead to high cardinality when enabled. The hash is configurable.
• probe_failed_due_to_hash contains a metric that indicates if the probe failed because the content hash did not match the expected value.

Resolves #351

[WillinuX-Code]

Hi there, thanks for this handy improvement. We are really looking forward for this check. Is there a timeline when this is going to be merged and possibly released?

[silkeh]

While I see the attraction of having a cryptographic checksum I wonder what use cases are solved by that which having a simple 32-bit checksum doesn't solve? I can see cases where people accidentally turn this on for dynamic content and get tons of cardinality.

I included it because there were people that had a use case for this in #351. For example:

This approach would be a perfect fit for monitoring the integrity of security.txt files and PGP public keys linked from there.

These files rarely change, so cardinality shouldn't be an issue.

(There is also another option here, if we used a larger hash function we could truncate it to 2^53 per https://stackoverflow.com/a/3793950 and still store that in a float64, meaning we'd have more than 32-bits of checksum but still use a simple integer. I would be surprised if anyone actually needs cryptographically secure hashing from their probes.)

That idea has crossed my mind, but having a value that can be converted to hex to verify seems more useful to me. Especially since the 53 bytes is still not enough to be cryptographically secure.