Remove go-semver dependency, plus various fixes

[anderseknert]

• Use a single eval to get both enabled regular and aggregate rules
• Prefer to use once-initialized io.Capabilities over ast.CapabilitiesForThisVersion
• Add rego.BuiltinsForDefaultCapabilities for the language server
• Some light refactoring, mainly to have code use existing util methods

[charlieegan3]

If these tests were copied from the coreos list, perhaps we should reference that here.

[anderseknert]

Yeah, I'll add a note. Thanks!

[charlieegan3]

All looks good to me!

[anderseknert]

Well this is certainly intriguing. CI fails because one particular test now exceeds the default 5 seconds timeout threshold! While the test obviously runs faster locally, the issue is easily seen here too, clocking in at almost a second!

  {
    "location": {
      "file": "bundle/regal/main/main_test.rego",
      "row": 285,
      "col": 1
    },
    "package": "data.regal.main_test",
    "name": "test_lint_from_stdin_disables_rules_depending_on_filename_creates_notices",
    "duration": 946422292,
  }

Now trying to understand what in this change possibly could cause this. The regal lint bundle benchmark doesn't show any equivalent regression, making this even more of a mystery. Will report back later on what I find.

[anderseknert]

(Also, making a note for us to change that threshold to 1 second once this is fixed. Even in CI, I don't think we'll ever have individual tests take that long unless there's an issue somewhere... and we'd want to know that sooner rather than later)

[anderseknert]

Looks like this is caused the rules that were previously external queries but moved into policy with this PR:

# METADATA
# description: enabled regular rules (LSP usecase only)
enabled.rules.regular contains rule if {
	some cat, rule
	data.regal.rules[cat][rule]
	object.get(data.regal.rules[cat][rule], "notices", set()) == set()
	not config.ignored_rule(cat, rule)
	not rule in enabled.rules.aggregate
}

# METADATA
# description: enabled aggregate rules (LSP usecase only)
enabled.rules.aggregate contains rule if {
	some cat, rule
	data.regal.rules[cat][rule].aggregate
	not config.ignored_rule(cat, rule)
}

I did not look closely at what these do, but they clearly trigger a full evaluation of all rules 😅 Which previously would happen only when the language server started or config got reloaded. Why this particular test triggers this is beyond me... but perhaps it's just where it's reported? 🤔 I will revert this change for now, but we will need to prioritize having this fixed in the language server too, as this blocks the initialize method, causing a long delay until the client gets to a working state.

[anderseknert]

I went ahead and fixed the above issue instead, Now it performs really well, but sadly using a little less Rego. Fixing that will be for a future change :)