Memory management improvements

[erwinkramer]

⚠️ The PR and description are vibe coded. I have no serious knowledge of Go or the project.

This PR introduces improvements to path normalization in the filesystem abstraction, enhances memory safety for metric label handling, and refactors the transaction finalization logic in the HTTP context. The changes aim to make the codebase more robust and maintainable, especially in edge cases and concurrent scenarios.

Filesystem abstraction improvements

• Added path normalization using filepath.ToSlash in the wasmplugin/fs.go file, ensuring consistent handling of directory and file paths across different operating systems. I needed this because I'm testing on Windows. This affects ReadDir, ReadFile, and mapPath methods, and introduces the new normalizePath function. [1] [2] [3] [4]

Memory safety and metric label handling

• Modified NewHttpContext in wasmplugin/plugin.go to copy the metricLabelsKV slice, preventing accidental mutation of the original slice and ensuring thread safety. This might help towards fixing Memory leak #249.
• Added a unit test (TestNewHttpContextMetricLabelsCopy) in wasmplugin/plugin_test.go to verify that metricLabelsKV is copied correctly and changes in one context do not affect others or the plugin.

HTTP context transaction finalization

• Refactored OnHttpStreamDone in wasmplugin/plugin.go to always perform logging and transaction closure, even if the transaction is nil or certain conditions are met. This ensures proper resource cleanup and consistent logging, especially important for TinyGo memory management. This might help towards fixing Memory leak #249.

Test robustness

• Changed test behavior in main_test.go to skip tests when the required wasm file is missing, providing a clear message and instructions to generate it, instead of failing the test.

[jcchavezs]

Thanks but no thanks. We only accept serious memory management improvements.

[jptosso]

@erwinkramer wheat my colleague meant is that your PR was flagged as AI generated and we don't have a clear policy around AI code.
We don't expect you to write an ai generated description of the change, we know what the code does, we want metrics with justifications, we could easily tell Claude to just refactor everything with best practices but that's not how it works, we need a purpose, a set of manageable changes and detailed metrics about the changes. Remember this is deployed in production for critical infrastructure in thousands of companies.

• allocation reduction per transaction
• transactions per second
• cpu reduction
• etc

Feel free to continue with your pr as long as you can provide this information, and please for future PRs avoid ai description and full llm code