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

[shmsr]

Proposed commit message

Drop usage of SHA1 and replace with a better algorithm xxhash for sanitizing the filenames.

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.

[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.

[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?

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[shmsr]

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?

AFAIK it's a complete separate offering. So, switching from one mode to another, it is not even allowed. @kruskall can confirm in case if I am wrong here.

[shmsr]

I am thinking to merge it today/ tomorrow; could I please get approval if everything looks good?

[shmsr]

@faec Could you please review this PR again? I am planning to merge it today if there are no further comments.

[pierrehilbert]

@shmsr Fae will be out until tomorrow so she won't be able to review it once again today.

[shmsr]

@shmsr Fae will be out until tomorrow so she won't be able to review it once again today.

ah, ok. Then can someone else take a look? I just want to get it reviewed before everyone leaves for EAH.

[belimawr]

LGTM, however I'm missing a changelog entry stating that upgrading to this version will cause the cache invalidation once.

@shmsr, do you have an idea (or is it possible to measure) what would be the performance impact upon upgrade?

I don't know much about this input, but invalidating the whole cache is similar to a cold start, so my understanding is that the performance impact would not cause problems, however it would be nice to confirm that.

[shmsr]

LGTM, however I'm missing a changelog entry stating that upgrading to this version will cause the cache invalidation once.

I will add an entry.

@shmsr, do you have an idea (or is it possible to measure) what would be the performance impact upon upgrade?

From the code, it looks like it's being used for an inexpensive op. I checked the usage of methods of the cache, and it was being used to get CF app info (GetAppByGuid; here). So, I see a very minimal impact. And this also happens once per processor's Run (here) method.

I don't know much about this input, but invalidating the whole cache is similar to a cold start, so my understanding is that the performance impact would not cause problems, however it would be nice to confirm that.

Yes.

[shmsr]

@elastic/ingest-docs Can I get a review on this? Added a CL entry.

[vishaangelova]

Thanks, LGTM!