libbeat: optimize asset data decoding

[mauri870]

Proposed commit message

While working on #41888 I was benchmarking the filebeatreceiver
CreateLogs factory and noticed that the asset decoding in libbeat
dominates the cpu and memory profile of the receiver creation.

This behavior is expected since asset decoding is intended to occur at
startup. However, it's still worthwhile to optimize it if possible.

Some time ago I worked on iobuf.ReadAll at
elastic/elastic-agent-libs#229, an optimized version of io.ReadAll
that has a better growth algorithm—based on bytes.Buffer—and
benefits from the io.ReaderFrom optimization. The choice of when to
use this is very picky, as using it with a reader that is not a
io.ReaderFrom can be slower than the standard io.ReadAll. For this
case we are certain of the reader implementation, so we can use it.
Benchmark results show that it is 5% faster and uses 17% less memory.

goos: linux
goarch: amd64
pkg: github.com/elastic/beats/v7/x-pack/filebeat/fbreceiver
cpu: Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz
           │   old.txt   │              new.txt               │
           │   sec/op    │   sec/op     vs base               │
Factory-32   9.506m ± 3%   8.962m ± 2%  -5.73% (p=0.000 n=10)

           │   old.txt    │               new.txt                │
           │     B/op     │     B/op      vs base                │
Factory-32   12.89Mi ± 0%   10.68Mi ± 0%  -17.20% (p=0.000 n=10)

           │   old.txt   │              new.txt               │
           │  allocs/op  │  allocs/op   vs base               │
Factory-32   5.083k ± 0%   4.944k ± 0%  -2.74% (p=0.000 n=10)

After these fixes the profiles are still dominated by the asset
decoding, but I guess that is expected, at least it is a bit faster now.

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 @mauri870? 🙏.
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

[mergify]

backport-8.x has been added to help with the transition to the new branch 8.x.
If you don't need it please use backport-skip label and remove the backport-8.x label.

[mauri870]

/test

[elasticmachine]

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

[Kavindu-Dodan]

It seems this introduced a build issue. I get vet: fbreceiver/receiver_test.go:133:26: NewFactory().CreateLogsReceiver undefined (type receiver.Factory has no field or method CreateLogsReceiver) ¹ from recent builds.

Footnotes

1. https://github.com/elastic/beats/actions/runs/12588586152/job/35086765916?pr=41817#step:8:216 ↩

[mauri870]

It seems this introduced a build issue.

Yes, that is fixed in #42199.