Null Fastval should not output as 0 when used as numeric values

[nelio2k]

Right now a NullValue Fastval outputs to 0 or 0.0 when its AsUint()/AsInt()/AsFloat64() is called.
Since 0 is commonly used as values, it could easily lead to an incorrect match. Consider the following test case that incorrectly matches:

	fe = &FilterExpression{}
	err = parser.ParseString("fieldpath.path IS NOT NULL", fe)
...
	userData := map[string]interface{}{
		"fieldpath": map[string]interface{}{
			"path": 0,
		},
	}
	udMarsh, _ := json.Marshal(userData)
	match, err := m.Match(udMarsh)
...

fieldpath.path is not null in this case but because the nil value on the right side of EqualsExpr inserted by the parser equates to 0 when matches with LHS's 0(int), this evaluation results in the incorrect value.

The simplest way to do it IMO is to make NullValue output MinInt64/MaxUint64/MaxFloat64 when AsInt()/AsUint()/AsFloat() is called. Chances are, those values are unlikely to exist in real world scenarios.

Another option is to do more complicated checks in CompareOp, which is more correct, but that will break the pretty symmetric function of the current code.

Thoughts, @brett19 ?

[brett19]

I imagine explicitly handling NULL and other special values in comparisons would probably be a valid implementation here. I'm not against the proposed alternative though.

[brett19]

You should leave this issue open, as I know you mentioned that you will likely improve the implementation of this to correctly special-case null values.

[nelio2k]

Hmm I forgot GitHub auto closes issues. Reopening now.