Rule: Allow st2kv in criteria, in addition to trigger payload

Currently you can only use criteria with a trigger that has payload, which means there is little flexibility for triggers that does not come with a payload, namely any of the timer triggers.

The proposed feature request is to allow st2kv in the criteria keys, which should make rules more flexible and easier to manage, whether with or without payload.

There may be need to restrict the st2kv to be system scoped, as user context in rule can lead to complicated issue.

Possible use cases:

# use st2kv.system.release_branch_freeze variable to decide 
# whether the cron job for build_regress job should be run
trigger:
  type: core.st2.CronTimer
  parameters:
    timezone: "UTC"
    day_of_week: "*"
    hour: "*/2"
    minute: 0
    second: 0

criteria:
  st2kv.system.release_branch_freeze:
    type: "eq"
    pattern : false

action:
  ref: devops.build_regress_submit_workflow

# A combination of both trigger payload and st2kv criteria use case

# This example stop auto-remediation when st2kv.system.maintenance_state is true 
# even if we received alert
# While this is possible to build in the action, it can be cleaner and more flexible if it is built in rule
# This way the action won't be triggered automatically, but can still be executed manually 
# without tweaking the st2kv or adding flag in the action

trigger:
  type: core.st2.webhook
  parameters:
    url: sensu

criteria:
  st2kv.system.maintainence_state:
    type: "nequals"
    pattern : true
  trigger.body.check.state:
    type: "equals"
    pattern: "failing"
  trigger.body.check.metadata.name:
    type: "equals"
    pattern: "service_check"
action:
  ref: ops.service_remediation
  parameters:
    host: "{{ trigger.body.entity.system.hostname }}"

Start by tracing how rule criteria currently resolve trigger payload values, then identify where st2kv lookups are handled for rules. Compare the timer-only and combined payload/st2kv examples, and determine how system-scoped access should behave. Done means both use cases work without a trigger payload while preserving existing payload criteria behavior.