Add test command to verify version collisions do not occur

[brokensound77]

Issues

related to #2251

Summary

If a forked rule (a rule that was previously locked and a subsequent min_stack_version was added - this can be tracked by any rule with a previous entry in the lock file) gets changes, there are no checks to ensure that the change will result in a version collision with a future state of the rule.

This adds a command to check for version space, which will be executed in the incrementally in the lock-multiple.sh script as part of the lock-versions workflow.

[brokensound77]

While this code worked, the flaw was that it relied on the root (current) version as a comparison. This meant that when the root version incremented, it would quietly allow previous entries to creep as well.

L290-295 instead use the newly pinned max_allowable_version to keep a static check

[brokensound77]

We potentially could run this in all unit tests where a rule file is changed to be really thorough, but I think for now we should leave it as a manual command

[brokensound77]

While running the new test-version-lock command to simulate the full iteration of the lock. It worked great as expected and actually errored out as expected. The issue appears to be an unrelated bug where the previous version of 17 rules are incrementing but instead of incrementing 1 version, they are taking the root version (100) (this is the bug, which was reproduced in the lock workflow and can be seen here).

So when it eventually gets to the root version, it detects that a previous entry is higher (as expected). So the 2 things to figure out:

• what is special about those 17 rules that they are different in 7.16 vs 8.3+ (not necessarily tied to the bug)
• why is a previous entry (forked rule) with changes inheriting the root version vs incrementing by 1 (as it should)

Again, these bugs are separate from this PR, but before merging, we should investigate a bit more to fully understand the resolution, since this modifies the version.lock (with the maxes)

[terrancedejesus]

Checked out 7.16 and ran the build-release --update-version-lock command to identify which rules versions were jumping all buffer space.

Outlier chosen: rule.name == Potential Credential Access via Windows Utilities
Issue: 7.16 forked version goes from 9 -> 101

The issue appears to stem from having multiple forked rules and route C specifically on line 281.

info_from_rule - The latest forked content, 8.3 and version 100
info_from_file - The current stack, 7.16, and version 9

If these do not match, as expected, it will set the 7.16 forked entry to the 8.3 entry and update that rule version as well.

We do have a TODO note in here to determine supporting old locked versions so maybe this is the right time to discuss and update this route.

I am not sure why these 17 specific rules are hitting this bug as every rule should have a previous 7.16 forked entry and forked again at 8.3 as they don't have rule content changes based on the SHA256 hash. This may also point to the bug as well, for some reason when lock_from_rule is defined, rules that are not included in this list of 17 have the previous forked entry version whereas the 17 has the latest forked version.

[brokensound77]

unnecessary bump resolution.

Still need to fix the massive version jump for legitimate cases though.

[Mikaayenson]

LGTM for this split merge

[brokensound77]

I am not sure why these 17 specific rules are hitting this bug as every rule should have a previous 7.16 forked entry and forked again at 8.3 as they don't have rule content changes based on the SHA256 hash. This may also point to the bug as well, for some reason when lock_from_rule is defined, rules that are not included in this list of 17 have the previous forked entry version whereas the 17 has the latest forked version.

There was just misalignment between the rule min stack and corresponding lock. Fix normalizes them to be major.minor to match