mu - changes on LambdaRetry max_attempts

[kk1532]

In the current c7n code, we’re not allowed to use the config-poll-rule mode if the resource in the policy is natively supported by AWS Config. Instead, we are forced to use the config-rule mode. While this is OK for most of the scenarios, there are cases where we can’t use config-rule mode. For example, we need to have a policy for marking VPCs as compliant/noncompliant in AWS Config based on their flow logs settings. Here’s an example for such policy:

policies:
   - name: vpcflowlog
     resource: vpc
     description: |
         Check if vpc flow log is enabled for all traffic and with s3 bucket as destination.
     mode:
       type: config-rule
       role: arn:aws:iam::{account_id}:role/MyRole
     filters:
       - not:
          - type: flow-logs
            destination-type: "s3"
            enabled: True
            status: active
            traffic-type: all
            destination: "arn:aws:s3:::mys3flowlogbucket"

The problem here is that the policy will work for the initial Config evaluation. However, after that, if the VPCs flow log settings are updated, such event will NOT trigger AWS Config for re-evaluation. I believe this is because in Config, flow logs are treated as a separate resource type and are not part of VPCs. As a result, the VPCs statuses in Config end up being out of date. To solve this problem, we can use config-poll-rule mode to update things at some interval. However, as mentioned before, we’re currently not allowed to use config-poll-rule mode if c7n detects that the resource is natively supported in Config. This PR allows users to ignore such check via a ignoreconfigsupportcheck flag. Here’s what a new policy would look like

policies:
   - name: vpcflowlog
     resource: vpc
     description: |
         Check if vpc flow log is enabled for all traffic and with s3 bucket as destination.
     mode:
       type: config-poll-rule
       role: arn:aws:iam::{account_id}:role/MyRole
       ignoreconfigsupportcheck: True
     filters:
       - not:
          - type: flow-logs
            destination-type: "s3"
            enabled: True
            status: active
            traffic-type: all
            destination: "arn:aws:s3:::mys3flowlogbucket"

Along with above code change, I have added fix for racing condition on Lambda attaching to AWS Config rule before Lambda get activate. I have increased max_attempts from 2 to 5 and added InvalidParameterValueException on retry exception list. This code fix will take care of below policy deploy error.

botocore.errorfactory.InvalidParameterValueException: An error occurred (InvalidParameterValueException) when calling the PutConfigRule operation: The specified AWS Lambda function is not in Active state. Please retry after sometime