Add constant comparison operator to jq evaluation

[eleftherias]

Summary

This adds a constant field to the jq evaluation engine.
This allows us to write ruletypes like the one below, which compares the evaluation result to a constant value, rather than requiring the profile to supply to value.

The example below compares the field delete_branch_on_merge in the evaluation result to the constant true.

def:
  in_entity: repository
  rule_schema:
    type: object
    properties: {}
  ingest:
    type: rest
    rest:
      endpoint: "/repos/{{.Entity.Owner}}/{{.Entity.Name}}"
      parse: json
  eval:
    type: jq
    jq:
    - ingested:
        def: '.delete_branch_on_merge'
      constant: true

This also changes the jq equality check to not differentiate between number type (int, float64 etc).
The alternative would be to let the user specify the type of their number constant, but I'm making the assumption that the likeliness of someone needing that is small, and not worth the additional overhead of setting a type every time.

Ref mindersec/minder-rules-and-profiles#156

I will update the docs once this is approved.

Change Type

Mark the type of change your PR introduces:

• Bug fix (resolves an issue without affecting existing features)
• Feature (adds new functionality without breaking changes)
• Breaking change (may impact existing functionalities or require documentation updates)
• Documentation (updates or additions to documentation)
• Refactoring or test improvements (no bug fixes or new functionality)

Testing

Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.

Review Checklist:

• Reviewed my own code for quality and clarity.
• Added comments to complex or tricky code sections.
• Updated any affected documentation.
• Included tests that validate the fix or feature.
• Checked that related changes are merged.

[coveralls]

coverage: 52.865% (+0.008%) from 52.857%
when pulling be38dd9 on eleftherias:jq-rule-with-constant
into 6f89a1d on stacklok:main.

[evankanderson]

This makes a lot of sense, and it's sort of amazing that it was missing for so long. Thanks for adding the test coverage, too!

[evankanderson]

Do you want Profile and Constant to be XOR (at least one set, but not both)?

[eleftherias]

Good point, I've updated it

[evankanderson]

How does this work for booleans (like your example)? I believe you that it does, but I was surprised to see that it worked.

Oh, I see! numberToFloat64 actually returns any, and passes through other values. I'm trying to figure out if there's a better name -- maybe standardizeNumbers?

[eleftherias]

Updated the name

[evankanderson]

I think you can write this as:

Suggested change

	Constant: &structpb.Value{
	Kind: &structpb.Value_BoolValue{
	BoolValue: false,
	},
	Constant: &structpb.NewBoolValue(false),

[evankanderson]

I love that we're testing list input. 🎉

Again, I think the helpers in structpb will make this less painful to read and write:

Suggested change

	Constant: &structpb.Value{
	Kind: &structpb.Value_ListValue{
	ListValue: &structpb.ListValue{
	Values: []*structpb.Value{
	{
	Kind: &structpb.Value_StringValue{
	StringValue: "a",
	},
	},
	{
	Kind: &structpb.Value_StringValue{
	StringValue: "b",
	},
	},
	{
	Kind: &structpb.Value_StringValue{
	StringValue: "c",
	},
	},
	},
	},
	},
	},
	Constant: &structpb.NewListValue(structpb.ListValue{Values: {
	structpb.NewStringValue("a"),
	structpb.NewStringValue("b"),
	structpb.NewStringValue("c"),
	},
	}}),

Unfortunately, NewList returns a *ListValue, error, so we can't just feed it into NewListValue directly. (We could also do it outside the function, or write an errorToPanic[T](T, err) T helper method.)