[FR] Add Fork Context to Version Lock

[Mikaayenson]

Is your feature request related to a problem? Please describe.

When we fork rules, we store the previous version information in our version_lock.json file. For example

 "max_allowable_version": 99,
 "rule_name": "Rule Name",
 "sha256": "hash",
 "type": "eql",
 "version": 4

We then update the toml file with new metadata. For example

min_stack_comments = "Description of why we min_stacked"
min_stack_version = "8.3.0"

However, we don't store that information in the lock_file.

Describe the solution you'd like

Now that we've locked all of our rules at 8.3.0, we should begin to the min_stack_comments to the version_lock to preserve the historical information (if it exist). That way we can ensure (unit test) rules are receiving comment updates when we bump the rule min_stack, and it makes it easier to track progress of rules across many branches.

 "max_allowable_version": 99,
 "min_stack_comments":  "Description of why we min_stacked"
 "rule_name": "Rule Name",
 "sha256": "hash",
 "type": "eql",
 "version": 4

Describe alternatives you've considered
We should about adding previous_locks and potentially adding previous_lock information to the toml file, but we've punted this idea for now. #1946 (comment)

Additional context
In #2272 we added the "max_allowable_version". We should add a new field similar to this.

[botelastic]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Mikaayenson]

In the progress of spot checking the concept and ran across at least one rule:

• https://github.com/elastic/detection-rules/blob/8.4/rules/integrations/google_workspace/collection_google_drive_ownership_transferred_via_google_workspace.toml

This rule was min_stacked at 8.3 and has the correct min_stacked comments:

min_stack_comments = "New fields added: required_fields, related_integrations, setup"

However, it was min_stacked again at 8.4 and the comments were not updated. We could add a unit test moving forward to check for this (but we'd want the lock file in place to enable this unit test).

@terrancedejesus @eric-forte-elastic @brokensound77 Do we want to add duplicate comments into the lock file? We probably should add the redundancy.

[terrancedejesus]

We could add a unit test moving forward to check for this (but we'd want the lock file in place to enable this unit test).

I do not quite understand the "lock file in place to enable this unit test" statement? This requires we update the version lock schema in version_lock.py where it expects a type str. From here, we could add an assertion to check if the previous and current comments are the same and if so, fail. Thoughts?

If this is in regards to the rule semantic versioning, I think min-stack comments is fine to add to the version lock file to have context as to why the rule was forked, whereas major, minor and patch updates reflect what part of the rule.contents.data was changed.

[brokensound77]

I don't see why preserving the comment would not be a good thing. Just always need to be extra careful with the version lock code

[Mikaayenson]

I do not quite understand the "lock file in place to enable this unit test" statement? This requires we update the version lock schema in version_lock.py where it expects a type str. From here, we could add an assertion to check if the previous and current comments are the same and if so, fail. Thoughts?

It's just a thought. I like the comment in the lock file for historical purposes. If we do add it, then we can add a unit test to check and make sure that when we bump the min version, the update also will include changes to the comment.