Add support for reconciliation of router configs

[ngarratt]

Currently there is no way to cleanly reconfigure/repair the tunnels in a CSR that has been replaced (unless you have an off-system backup of the configuration). While looking at options for automating this, I also picked up a couple of related limitations:

• You can simulate S3 Put events to have the configurator re-run existing configs, but this has to be done manually for each VPN connection to each CSR
• Each time the configurator fires for a VPN, it creates a new tunnel. So if you simulate events as above, you can end up with duplicate tunnels (the duplicate will be incomplete due to IP conflict)
• Untagging a VGW after duplicate tunnels have been created will remove the duplicates but not the originals
• If a VGW is removed (not untagged), this results in orphan VPN configs. Blindly re-running all existing configs will result in superfluous tunnels

This pull fixes these and adds support for a reconciliation event running on a regular schedule (every 6 hours).

New features:

1. During VGW processing, orphan VPN configs are identified and changed to delete status. This only runs if the environment is stable (no other VGW processing completed that cycle), and only runs if the lambda is in the same account as the CSRs (will have visibility into all VPN connections).

2. During S3 events, VPN configs with delete status are removed as normal, but the S3 config is then disabled to prevent further processing.

3. During scheduled events, all active VPN configs are evaluated
   3.1. Existing tunnels will be updated/repaired as necessary. Warnings will be issued for any duplicate tunnels, but only the lower tunnels will be updated (these are the ones that will have valid configs)
   3.2. New tunnels will be created if necessary
   3.3. Tunnels marked for delete will be fully cleaned up (including any duplicates), then those S3 configs are disabled

It did require a refactor of some existing code to avoid duplication, and a change in behavior for the tunnel ID parameters being passed around (using lists of IDs rather than assuming a base+1).

We use Terraform for our deployments, but the necessary Cloudformation changes are included.

[bashoKa]

requiring this change as well.
+1

[hvital]

Thanks for your contribution. This PR will be evaluated for the next version and we'll update to this thread once we have more information.