feat(core): require conditional action

[topher-lo]

What changed

• Created an require action that takes one or more exprs
• exprs is not entirely accurate, since require functions like reshape (a more accurate argument might be bool, but from the UI perspective might be misleading since what the user sees is the template expression not bool). I went for exprs for user clarity over functional accuracy.
• Called require because assert is a key variable in python.
• require is used in Kotlin and Solidity
• core.require is semantic closest what to what I want it to do in templates (e.g. require URLScan POST result to have a successful status otherwise fail).
• Also drops "!" in OPERATORS. It wasn't in the grammar anyway.

Bigger changes

• Extended the grammar to support more operators
• Note that is not and not in are at the front to avoid is and in being evaluated first
• Extended OPERATORS infunctions.py

QA

• Added simple tests in registry/test_core_require.py which just checks bools as inputs (i.e.as post evaluated templates)
• Added test_expression_binary_ops with a case for each operator to unit/test_expressions.py

Future considerations

• Maybe support match_any?
• We should probably test require in a workflow, but I'm just relying on induction: since require is logically equivalent to core.transform.reshape except it supports lists of exprs, which we do test.

Prior art

• https://docs.projectdiscovery.io/templates/reference/matchers#types
• https://docs.soliditylang.org/en/latest/control-structures.html#panic-via-assert-and-error-via-require

[daryllimyt]

No need to use try-except, just check the value and throw. Also no need return value. Also, is lhs and rhs too rigid? How do we handle container emptiness checks? Would we have to do:

lhs: FN.length(<container>)
rhs: 0
condition: ==

[daryllimyt]

Will document that result from this action shouldn't be used (is falsely None). It's just a gate

Since people might try using this, let's keep returning True in the happy path to distinguish between None that would be returned in the error path.

[topher-lo]

Container checks will be a separate action https://www.tines.com/docs/actions/types/trigger/

Tines throws a bunch of stuff all in a single action with a dropdown for options. That's not very user friendly imo.

[topher-lo]

Also on closer look maybe not too rigid, all of Tines trigger rules are LHS, RHS, or regex

Can you think of any other cases other than is empty which operates on a single value?

[daryllimyt]

Container checks will be a separate action https://www.tines.com/docs/actions/types/trigger/

Tines throws a bunch of stuff all in a single action with a dropdown for options. That's not very user friendly imo.

Aren't in and not in container checks?

[daryllimyt]

Also on closer look maybe not too rigid, tines has a container is empty option for trigger, it really is just check length is 0.

Can you think of any other cases other than is empty which operates on a single value?

Any kind of FN.func() that returns a boolean/truthy or a standalone boolean value, but I suppose you would want users to compare against True or False using is/is not?

[topher-lo]

Yeah. I think this discussion getting too complicated. Question: is LHS and RHS too rigid? I think it's flexible enough for folks to use FN along with the supported operators to achieve what they need

Following our private discussion, I'll drop lhs and rhs and instead use a if-condition single expression style system

[daryllimyt]

LGTM, i think would be great if you could add an actual action template run to test your main usecase (throwing from template). See test_registry for examples on running template actions

[daryllimyt]

check empty list behavior as well?