Add filesource provider

[blakerouse]

What does this PR do?

Adds the filesource provide to composable.

The provider watches for changes of the files and updates the values of the variables when the content of the file changes.

Why is it important?

This allows information from the filesystem to be used as variables in the Elastic Agent configuration. This information is only allowed by explicitly configuring the provider to read this information from the disk. The policy cannot just read any file, it has to be explicitly configured to allow it.

Checklist

• I have read and understood the pull request guidelines of this project.
• 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/fragments using the changelog tool
• [ ] I have added an integration test or an E2E test (covered by unit tests well)

Disruptive User Impact

None

How to test this PR locally

Create a configuration:

elastic-agent.yml

provides:
  filesource:
    sources:
      file1:
        path: ./file1

inputs:
 - id: filestream
   type: filestream
   paths:
     - ${filesource.file1}

echo "/var/log/syslog" > ./file1

Observe that syslog is set to paths.

Related issues

• Closes Add filesource provider to composable inputs #6362

[elasticmachine]

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

[kaanyalti]

changes look good to me

[elastic-sonarqube]

Quality Gate passed

Issues
3 New issues
0 Fixed issues
0 Accepted issues

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

See analysis details on SonarQube

[pkoutsovasilis]

LGTM with a note: I’d prefer a design with more isolation between event consumption and the file content reading. For instance, a goroutine could handle fsnotify events and mark map entries as “dirty,” while another periodically processes these at its own pace. This would mitigate risks like event overflow or frequent re-rendering caused by rapidly changing files (which even a malicious entity could try to exploit).

That said, let’s remain profile-driven - if issues arise, we can iterate and refine the solution as needed.

[cmacknz]

You can file an issue in https://github.com/elastic/ingest-docs describing how this works to get it included in the provider documentation, assuming we want this available outside of internal use.