x-pack/libbeat/common/cloudfoundry: Use xxhash instead of SHA1 in FIPS mode

[shmsr]

Proposed commit message

Drop usage of SHA1 and replace with a better algorithm when running in FIPS mode (-requirefips).

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

[botelastic]

This pull request doesn't have a Team:<team> label.

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @shmsr? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-8./d is the label to automatically backport to the 8./d branch. /d is the digit
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

[kruskall]

question: do we need a cryptographic function ? If not, I'd suggest we use a non-cryptographic func (e.g. xxhash) to make this more future-proof.

[shmsr]

Yes makes sense. I'll do this.

[kruskall]

question: Can we update the cache key for everyone ? Would this be considered a breaking change ?

[shmsr]

I am also not sure about this. Since sha1.Sum is deterministic, it will always produce the same hash for a fixed input (in this case, the APIAddress). This deterministic behavior means the system might create or reuse a (persistent) cache based on this hash value.

For users who already have that persistent cache in place, changing this logic could potentially be a breaking change. Although it's just a cache implementation detail, I haven't deeply investigated this issue since I haven't worked with cloudfoundry before.

[belimawr]

It would be nice to better understand the implications of changing the cache key so we could assess whether it makes sense to use a single implementation to FIPS and non-FIPS.

[belimawr]

I believe it ends up being just a variation of the same question asked by @kruskall: what happens if someone upgrades Beats to the FIPS version? Is this upgrade even supported?