Filestream reingests data when `clean_inactive` is set

[faec]

The documentation for clean_inactive says that file state can only be removed if the file is already ignored by Filebeat using the ignore_older setting. However, clean_inactive takes effect even when ignore_older is disabled.

The documentation also says that clean_inactive must be greater than ignore_older + prospector.scanner.check_interval. However, this constraint is ignored; clean_inactive is unaffected by ignore_older and prospector.scanner.check_interval, and regardless of their values the setting clean_inactive: 0 will always reingest all files every time Filebeat is run.

The documentation for the clean_inactive in filestream is identical to the documentation for the same flag in the log input, and accurately describes how the log input behaves: if clean_inactive is set without enabling ignore_older, or if clean_inactive < ignore_older + scan_frequency, the input reports a fatal configuration error on startup.

(Additionally, in the log input, setting clean_inactive: 0 disables the flag, and is the default setting. In the filestream input, setting clean_inactive: 0 enables the flag, and reingests everything immediately on startup. This difference is not mentioned in the documentation, but does not explicitly contradict it.)

Related issues / PRs:

• Filestream ignores clean_inactive #36629 (before 8.14, clean_inactive was documented the same as today, but was ignored unconditionally)
• Fix clean_inactive for Filestream input #38632 (the initial implementation of clean_inactive in filestream after the previous bug was noticed)
• Filestream clean_inactive does not work as expected #40178 (reporting a more severe version of the current issue, where registry entries were removed after 30 minutes even without enabling clean_inactive, but does not mention other symptoms)
• [bug][filestream] - Fix filebeat GC cleanup bug  #40258 (fixed the issue with deleting entries by default, but did not address the other behavior reported by the current issue)
• Filestream bases clean_inactive on process start time, not file update time #45600 (another current bug where time intervals related to clean_inactive are calculated incorrectly)

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[cmacknz]

After discussion, this should behave the same way it does for the log input the way the documentation implies it should. If it doesn't match, we'll have to special case this when migrating from log to filestream.

[cmacknz]

• For future versions, we should fix this to match
• For previous versions, we should mark it as a known issue and update documentation to say what it actually does

[belimawr]

• For future versions, we should fix this to match

@cmacknz, that means making clean_inactive: 0 on Filestream disabling the clean inactive feature, right?

It is a change in behaviour, but I can't picture a real use case where someone wants to re-ingest all files on every restart. So I like the idea. I tried this out on my draft PR and it looks a simple change.

Whenever clean_inactive: 0 we set it to -1, so the code changes are minimal and mostly around configuration parsing/management.

[cmacknz]

What I wrote in retrospect is not very clear and it's been long enough that I don't remember the context.

What I think I meant would be to fix filestream to behave exactly like the log input does to match it's current documentation, which is what most people are assuming the behaviour probably is.

There is probably someone out there using clean_inactive: 0 to re-ingest data on restart on purpose, so we should document an alternate way for these users to achieve this in the release notes and documentation if possible.

I generally take making a parameter behave the way we've described it should for years as a bug fix and not a breaking change.