Inconsistent OPA number handling

[alvarogomez93]

Short description

When using aliases or variables from a path, number type coercion doesn't work consistently. You get into a scenario where 1.0 == 1 evals to false. This can be avoided assigning the aliased value to an intermediary rule, however this behavior is not predictable and should get fixed.

Example:

Input:

{
    "oneDotZero": 1.0
}

Rule:

default bug := false
bug {
	input.oneDotZero == 1.0 # if you set this to 1 it returns true
}

Output:

{
    "bug": false,
}

Steps To Reproduce

Playground where this is reproduced and workaround is provided https://play.openpolicyagent.org/p/RbcP7xO0eW (replace 1 for 1.0 in oneDotZero, rego playground changes this automatically when publishing)

Expected behavior

Using aliases should behave similarly to other expressions

[anderseknert]

Adding to this, evaluation differes between rule head and rule body in this regard: https://play.openpolicyagent.org/p/DujkIZh56k

With input as {"i":1.0}:

package play

# true
x := input.i == 1.0

# not true
allow {
	input.i == 1.0
}

The compiler rewrites the former to use equal, and the latter to use unification (=):

package play

x := __local0__ { true; __local1__ = input.i; equal(__local1__, 1.0, __local0__) }
allow = true { input.i = 1.0 }

[srenatus]

The compiler rewrites the former to use equal, and the latter to use unification (=)

Huh that's surprising. I would have expected the stage that rewrites equal to unification to cover both cases.