fix(aggregate transform): keep previous metrics only for diff mode

[esensar]

Summary

Aggregate transform keeps track of previous aggregated values for use in diff aggregate mode - the issue is that this state is held even for other aggregate modes, resulting in doubled memory usage for no real reason.

Change Type

• Bug fix
• New feature
• Non-functional (chore, refactoring, docs)
• Performance

Is this a breaking change?

• Yes
• No

Does this PR include user facing changes?

• Yes. Please add a changelog fragment based on our guidelines.
• No. A maintainer will apply the no-changelog label to this PR.

References

• Related: log_to_metric memory use - double what is required? #24589

Notes

• Please read our Vector contributor resources.
• Do not hesitate to use @vectordotdev/vector to reach out to us regarding this PR.
• Some CI checks run only after we manually approve them.
  • We recommend adding a pre-push hook, please see this template.
  • Alternatively, we recommend running the following locally before pushing to the remote branch:
    • make fmt
    • make check-clippy (if there are failures it's possible some of them can be fixed with make clippy-fix)
    • make test
• After a review is requested, please avoid force pushes to help us review incrementally.
  • Feel free to push as many commits as you want. They will be squashed into one before merging.
  • For example, you can run git merge origin master and git push.
• If this PR introduces changes Vector dependencies (modifies Cargo.lock), please
  run make build-licenses to regenerate the license inventory and commit the changes (if any). More details here.

---

Sponsored by Quad9

[thomasqueirozb]

Hi @esensar, I just created #24943 which extracts some refactoring I did in #24357 (locally only) and will make this PR obsolete. Thanks for your work on this though! As we discussed in that discussion before I hope we can figure out a full fix for #23093

[esensar]

Hi @esensar, I just created #24943 which extracts some refactoring I did in #24357 (locally only) and will make this PR obsolete. Thanks for your work on this though! As we discussed in that discussion before I hope we can figure out a full fix for #23093

Nice, that approach makes more sense.