Feature request: Make PollingSensor's poll_interval configurable (dynamically)

Currently, if I have a pack with a sensor in two different StackStorm instances, the only ways to set a different poll_interval for the PollingSensor is to override /opt/stackstorm/packs/<pack>/sensors/<sensor>.yaml or make change the sensor's setup() or __init__() to retrieve the poll_interval from somewhere in self._config.

Please make some kind of sensor configuration mechanism to change the poll_interval for sensors without modifying the pack. That could be something like /opt/stackstorm/configs/<pack>/sensors.yaml or /opt/stackstorm/configs/<pack>/sensor_poll_interval.yaml with contents like:

---
sensor_name: 3600
sensor2: 30
other_sensor: 42

Other than poll_interval, nothing else in the <sensor>.yaml file would make sense to override.

Also, I would like to take the configurability of the poll_interval one step further: I want a dynamic poll_interval. So, as part of a workflow, I want to be able to speed up, or slow down the poll_interval for the duration of the workflow. That would probably mean having some st2sensorcontainer api for changing the poll interval of a particular sensor, and some kind of communication socket or signal that st2sensorcontainer can send to the sensor_wrapper to change the poll_interval.

The dynamic nature of poll_interval could also be useful on a schedule. For example, poll this service every 30 seconds during business hours, and every 5 seconds after business hours (or the opposite). Or during peak hours, poll this service less often to prevent creating our own DoS. etc.

Once there was such an api on st2sensorcontainer, I can imagine having an API to kick a sensor (ignore poll_interval, check now!) from within an action or workflow. But that might need to be a separate feature request.

Start by reading the PollingSensor setup()/init() configuration path, then inspect st2sensorcontainer and sensor_wrapper for existing sensor communication. Define how per-sensor configuration and runtime poll_interval changes should be represented and delivered. Done means both static overrides and dynamic changes work without modifying a pack, with behavior covered by appropriate tests.