Don't deepcopy AST when generating vars

[swiatekm]

What does this PR do?

We generate vars from mappings from both context providers and dynamic providers. Dynamic providers can produce multiple var entries - the Kubernetes provider will do so for each Pod, for example. When that happens, we currently make a deep copy of the context provider mapping, and add the dynamic provider mapping as a key.

As we don't modify the mappings, this deep copy can be replaced by a shallow copy. This PR introduces shallow copying to the AST and uses it when generating vars, leading to a major performance improvement.

Why is it important?

All these deep copies can be quite expensive when there's a lot of mappings from the dynamic provider. See the benchstat report below:

goos: linux
goarch: amd64
pkg: github.com/elastic/elastic-agent/internal/pkg/composable
cpu: 13th Gen Intel(R) Core(TM) i7-13700H
                       │ bench_main.txt │          bench_shallow.txt          │
                       │     sec/op     │   sec/op     vs base                │
GenerateVars100Pods-20    15247.8µ ± 4%   778.8µ ± 7%  -94.89% (p=0.000 n=10)

                       │ bench_main.txt │          bench_shallow.txt           │
                       │      B/op      │     B/op      vs base                │
GenerateVars100Pods-20   10273.4Ki ± 0%   779.1Ki ± 0%  -92.42% (p=0.000 n=10)

                       │ bench_main.txt │          bench_shallow.txt          │
                       │   allocs/op    │  allocs/op   vs base                │
GenerateVars100Pods-20     201.28k ± 0%   22.13k ± 0%  -89.00% (p=0.000 n=10)

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in ./changelog/fragments using the changelog tool

Related issues

• Relates Elastic agent uses too much memory per Pod in k8s #5835
• Relates Memory Consumption Issue with Elastic Agent on Kubernetes with high number of resources #5991

[mergify]

This pull request does not have a backport label. Could you fix it @swiatekm? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-./d./d is the label to automatically backport to the 8./d branch. /d is the digit

[mergify]

backport-v8.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.

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
82.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[blakerouse]

Really nice! Looks good.

[amitkanfer]

🚀

[pierrehilbert]

@swiatekm I think we want to backport this to 8.17 also. WDYT?

[amitkanfer]

@swiatekm I think we want to backport this to 8.17 also. WDYT?

Are we 100% sure there is no hidden bug here?

[pierrehilbert]

My two cents:

• We don't have the first BC for 8.17 yet
• We are backporting this to 8.15 and 8.16 so I hope we don't have an hidden bug here as the timeframe to test for those will be shorter than the 8.17 branch.

[swiatekm]

If anything, maybe we should skip the 8.15 backport? It's pretty close, and this isn't that critical of a fix. For 8.17, I think we should backport either way, but I could wait until 8.17.0 is out before merging the PR.

@swiatekm I think we want to backport this to 8.17 also. WDYT?

Are we 100% sure there is no hidden bug here?

I'm never going to claim 100% for a codebase I haven't been working on for at least a year. I am as sure as I can reasonably be, I think. In practice, the change only has an effect when one of the dynamic variable providers is used. For these:

• The local dynamic provider is used in unit tests
• I've done fairly extensive manual e2e testing on the kubernetes provider

I could also manually test the docker provider, but I can't think of any reason it would be affected when the others aren't.