Unexpected behavior of ETag

[Kale-Ko]

Describe the bug
When fetching different resources the same ETag is always returned even for wildly different content. This can lead to unexpected behavior of caches but in this case it combines with a Docker buildx bug to produce an issue, see docker/buildx#2803. It is also strange behavior that the ETag is returned for some resources only if the Content-Encoding is set to gzip.

To Reproduce

1. Run curl -X GET "https://api.adoptium.net/v3/assets/latest/8/hotspot" -H "Accept-Encoding: gzip" -o /dev/null -v and observe the ETag
2. Run curl -X GET "https://api.adoptium.net/v3/info/available_releases" -H "Accept-Encoding: gzip" -o /dev/null -v and observe the ETag is the same

Expected behavior
The ETag is different for different content, generally a hash of the content.

Device (please complete the following information):

• OS: Linux
• Browser: curl
• Version 8.11.0

[johnoliver]

#1278 should address this.

Re the content encoding, will have to dig into that, not aware of any reason why that would be the case