Improve error handling for invalid range key conditions

[ikonst]

For a condition to be a valid range key condition, it must:

1. operate on the range key
2. use one of the supported operators

Filter conditions cannot use range key attributes, so a condition whose only problem is an unsupported operator cannot be "demoted" to be a filter condition: we'd simply fail a few statements later with:

raise ValueError("'filter_condition' cannot contain key attributes")

Moreover, that message would've caught the user by suprirse, since the user passed it as a range_key_condition.

Changes:

1. The error messages now indicates the reason for the condition being invalid.
2. We only demote to a filter condition when permissible.
3. We now issue a warning in this case. Key conditions have different cost and this demotion could be harmful. We should consider deprecating it.
4. Removing the Condition.is_valid_range_key_condition method. It probably never served any purpose except to be used in this code, and I think it's a good candidate for deprecation in pynamodb 5.x.

[jpinner-lyft]

TIOLI: i think this change makes the code less readable

[ikonst]

I don't think Condition needs a is_valid_range_key_condition method: I don't think it's a very likely scenario for a user to take a condition and, say, try to determine dynamically if it can be used as a range condition.

I agree it can be refactored into a method in TableConnection.query which is the only place where it's used now.

[jpinner-lyft]

Wondering if it would be easier to just warn on the demotion and then remove it outright instead of trying to fix the error handling. Thoughts?

[ikonst]

Wondering if it would be easier to just warn on the demotion and then remove it outright instead of trying to fix the error handling.

Can we just remove it in 5.x?

[ikonst]

Also, isn't it valuable to have two error messages instead of one?