feat: added file capability [APMSP-3780]

[Aaalibaba42]

What ?

Implement js side of FileCapabilities for interacting with the FS.

Why ?

Required #166 mentioned comment, these should be done by libdatadog so that libdatadog-nodejs don't need to get those infos like this.

How ?

New capability for interacting with FS driven by Rust

[github-actions]

Overall package size

Self size: 30.26 MB
Deduped: 30.26 MB
No deduping: 30.26 MB

Dependency sizes

| name | version | self size | total size | |------|---------|-----------|------------|

_{🤖 This report was automatically generated by heaviest-objects-in-the-universe}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9e13e690d3

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[Copilot]

Pull request overview

Implements a new wasm/Node.js-backed FileCapability so libdatadog (via wasm) can interact with the filesystem through a JS transport, and updates the libdatadog git rev to pick up upstream capability support.

Changes:

• Add WasmFileCapability (Rust) plus a Node.js file_transport.js shim for read/write/metadata/exists.
• Wire file capability into the WasmCapabilities bundle and add a Node test for the JS transport.
• Update libdatadog git revision and regenerate lockfiles; broaden ESLint transport filename exception.

Reviewed changes

Copilot reviewed 7 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
yarn.lock	Lockfile adjustments from dependency resolution changes.
test/file-transport.js	Adds Node test coverage for the JS file transport shim.
eslint.config.js	Broadens the filename-case exception to all *_transport.js shims.
crates/pipeline/Cargo.toml	Bumps libdatadog git rev for pipeline crate dependencies.
crates/capabilities/src/lib.rs	Adds file capability module and implements FileCapability for WasmCapabilities.
crates/capabilities/src/file.rs	New wasm FileCapability implementation calling into file_transport.js.
crates/capabilities/src/file_transport.js	New Node.js fs-backed transport shim used by wasm.
crates/capabilities/Cargo.toml	Bumps libdd-capabilities git rev.
Cargo.lock	Regenerated to reflect updated libdatadog rev and transitive deps.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Aaalibaba42]

I'm not sure what those detached buffers errors are from, it doesn't look like they are due to my changes directly, but maybe from libdatadog's bump ?

[ekump]

I'm not sure what those detached buffers errors are from, it doesn't look like they are due to my changes directly, but maybe from libdatadog's bump ?

@Aaalibaba42 Having a look at the failing test, we're creating 15k new strings, which I assume is causing the buffer to be resized. QueueOp checks for a detached buffer, but only at the start. Is it plausible that creating that many strings in a tight loop is triggering a memory.grow() in between the check and the call to this._cqbView?

It's not clear to me how the code in this PR would trigger a legitimate failure. My first guess would be this was a latent issue waiting to happen, and the changes in this PR changed the memory layout enough to trigger a memory.grow() at an inopportune time. But that's complete speculation on my part. I defer to @bengl to have a more informed take.

I wonder if the answer to this question is yes?

[ekump]

LGTM, but holding off an approval until we confirm the root cause of the failing test.