[Security Solution] Invalidate updated rules instead of marking them instantly stale

[maximpn]

Addresses: #151151

Summary

It's an improved fix of #151151. It helps to reduce the number of fetch data requests by reusing cache data when it's possible.

Before:

Screen.Recording.2023-03-23.at.14.33.35.mov

After:

Screen.Recording.2023-03-23.at.14.35.38.mov

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 53f778f

Failed CI Steps

• Security Solution Tests #1

Test Failures

• [job] [logs] Security Solution Tests #1 / Detections : Page Filters Alert Page Filters Customization Add New Controls
• [job] [logs] Security Solution Tests #1 / Detections : Page Filters Alert Page Filters Customization should not sync to the URL in edit mode but only in view mode

Metrics [docs]

Unknown metric groups

ESLint disabled line counts

id	before	after	diff
securitySolution	433	436	+3

Total ESLint disabled count

id	before	after	diff
securitySolution	513	516	+3

History

• 💔 Build #114932 failed cd6cc72

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @maximpn

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[xcrzx]

It introduces a high probability that we will display stale data eventually. Refetch type none prevents hooks that are currently rendered to refetch their data. Therefore if there is no updatedRules in the response, they will continue to display outdated data.

[xcrzx]

I gave it another thought, and keeping the stale time to 0 seems more appropriate. Rules contain dynamic data, such as "last run", "status", etc., that we may not know when it updates. As a result, we should consider the data as always stale and fetch updates each time a data fetching hook mounts. This approach helps avoid inconsistencies when a single rule is displayed under different filters, which could lead to conflicting information. For example, a rule might appear to have been executed 6 minutes ago in one view while displaying an execution time 1 minute ago in another. We can ensure that the information displayed remains consistent and accurate by fetching updates every time a hook mounts.

[maximpn]

After the careful investigation and discussion with @xcrzx the problem described in this comment was reproduced. To do that the following should be done

• have as minimum one rule
• enabled the rule with 1 second execution interval and 1 second look back time
• checkout the rules table, filter rules by enabled, refresh it, then reset the filter
• notice the difference in the lat run column, the value differs for the same rule but different filters activated

This way staleTime: 0 stays as the default caching option for the rules query. It invalidates the data right after it was fetched so each time a filter is activated it leads to sending a new request to fetch a fresh portion of the data. Any other ways to implement cache invalidation look more complex to implement and don't give clear benefits. So I close this PR.