[Security Solution][Detections] Removes the Tour for the new features on the Rule Management page introduced in 8.1

[banderror]

Ticket: #125504

Summary

This PR removes the Tour UI from components of the Rule Management page. We don't need to show 8.1 features in the 8.2.0 version. The Tour was previously introduced in #124343.

Details

• The tour steps are removed from the components (<EuiTourStep>).
• The tour provider is removed from the page. It has been changed a little bit.
• I thought it could be useful to leave the implementation for now, in case we want to show new tours in the next versions. If we don't use it during the next few dev cycles given we will be shipping new features on the Rule Management page, we will need to completely remove it from the codebase.
• A short README is added with some notes on the Tour UI.

[elasticmachine]

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

[elasticmachine]

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

[spong]

Checked out, tested locally (with carryover upgrade from your other tour PR), and LGTM! No issues in testing and code changes LGTM. Thank you for the additional comments and README to explain this functionality (why it's not enabled), and how to leverage it/update it in the future, really helps with context here . In agreement with keeping this code around for a release or two and then removing it at a later date. 👍

A side question, do we want to proactively remove these keys from the user's localstorage as part of these updates/removals? Do you know if the storage kibana.service has any sort of expiration cooked in, or is that all on the implementer? I would imagine the latter, but just curious here about these keys lingering around release over release...

[banderror]

@spong many thanks for your review 🙏

A side question, do we want to proactively remove these keys from the user's localstorage as part of these updates/removals?

Ideally - probably yes. But if we talk only about this storage key, IMHO it would be a very minor tech improvement compared to all the other tech stuff we can work on.

However, I'd say having a custom storage API in Kibana that would allow us to define some expiration and cleanup policy, as well as (and especially) versioning and migration for the stored data, could be useful.

Do you know if the storage kibana.service has any sort of expiration cooked in, or is that all on the implementer? I would imagine the latter, but just curious here about these keys lingering around release over release...

I wouldn't expect the storage exposed from Kibana services to implement any TTL/expiration/cleanup logic unless it was available in its interface explicitly. Meaning if we didn't set up a TTL for our key, Kibana shouldn't delete it based on some cleanup policy, because otherwise, it could break our app.

[banderror]

I'm going to update the added README based on the notes from #128405 (comment) and then will merge this guy.

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 5c906b3
• Storybooks Preview
• Webpack Bundle Analyzer

Test Failures

• [job] [logs] Security Solution Tests / value lists user with restricted access role "before each" hook for "Does not allow a t1 analyst user to upload a value list"

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
securitySolution	2986	2984	-2

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
securitySolution	4.8MB	4.8MB	-3.1KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
securitySolution	247.1KB	247.0KB	-99.0B

History

• 💚 Build #33457 succeeded d50e93a
• 💚 Build #33141 succeeded adaa518

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

cc @banderror