currently the policy-handler is active - it brings the latest policies to components on policy-update notifications (through web-socket) and periodic catchups.  In the passive(stand-by) mode of operation the policy-handler will turn off the web-socket to policy-engine and will also turn off the periodic catchup. 

a new /operation http API will be added to policy-handler,

the starting operation mode will be specified by the local etc/config.json.  No configuration through discovery for this feature

This will also allow having a resilient solution where several identical policy-handlers can run on the system with only one active and others in passive(stand-by) mode of operation

—

• mode_of_operation: active or passive
  • active is as before this change
  • in passive mode the policy-handler
    • closes the web-socket to PDP
    • skips the periodic catch_ups
    • still periodically checks for reconfigure
    • still allows using the web-server to retrieve policies from PDP
• default is active
• when mode_of_operation changes from passive to active, the policy-handler invokes the catch_up right away
• config-kv contains the optional override field mode_of_operation
  • changing the mode_of_operation in config-kv and invoking POST /reconfigure will bring the new value and change the mode of operation of the policy-handler if no service_activator section is provided in consul-kv record
• if config-kv contains the service_activator section,
  • the policy-handler registers with service_activator - untested
  • and receives the mode_of_operation - untested
  • service_activator can POST-notify the policy-handler to initiate the /reconfigure