Fix cloudfront_info pagination bug

[marknet15]

SUMMARY

Currently the cloudfront_info module is using a bespoke paginator function, which is causing some issues when over 100 distributions exist (see linked issue), when in fact it can be easily switched to a native boto3 paginator that would fix the bug reported in the linked issue.

Fixes #769

ISSUE TYPE

• Bugfix Pull Request

COMPONENT NAME

cloudfront_info

ADDITIONAL INFORMATION

Pagination docs: https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/cloudfront.html#paginators

Tests following steps from linked issue:
ran a ansible task:

- hosts: localhost
  connection: local
  gather_facts: false
  tasks:
    - name: "Check if distribution already exists"
      cloudfront_info:
        distribution: true
        domain_name_alias: "XX"
      register: distribution_data

Results:

TASK [Check if distribution already exists] ************************************************************************************************************************************************************************************************************************************
task path: /root/test/test.yml:6
<127.0.0.1> ESTABLISH LOCAL CONNECTION FOR USER: root
<127.0.0.1> EXEC /bin/sh -c 'echo ~root && sleep 0'
<127.0.0.1> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo /root/.ansible/tmp `"&& mkdir "` echo /root/.ansible/tmp/ansible-tmp-1635164453.7083595-389-139483031845166 `" && echo ansible-tmp-1635164453.7083595-389-139483031845166="` echo /root/.ansible/tmp/ansible-tmp-1635164453.7083595-389-139483031845166 `" ) && sleep 0'
Using module file /root/test/library/cloudfront_info.py
<127.0.0.1> PUT /root/.ansible/tmp/ansible-local-3861wn9tjv7/tmp6o0jv2s2 TO /root/.ansible/tmp/ansible-tmp-1635164453.7083595-389-139483031845166/AnsiballZ_cloudfront_info.py
<127.0.0.1> EXEC /bin/sh -c 'chmod u+x /root/.ansible/tmp/ansible-tmp-1635164453.7083595-389-139483031845166/ /root/.ansible/tmp/ansible-tmp-1635164453.7083595-389-139483031845166/AnsiballZ_cloudfront_info.py && sleep 0'
<127.0.0.1> EXEC /bin/sh -c '/usr/bin/python3 /root/.ansible/tmp/ansible-tmp-1635164453.7083595-389-139483031845166/AnsiballZ_cloudfront_info.py && sleep 0'
<127.0.0.1> EXEC /bin/sh -c 'rm -f -r /root/.ansible/tmp/ansible-tmp-1635164453.7083595-389-139483031845166/ > /dev/null 2>&1 && sleep 0'
ok: [localhost] => {
    "changed": false,
    "cloudfront": {
        "XXXXXX": {
            "Distribution": {
                "ARN": "arn:aws:cloudfront::XXXXXXXX:distribution/XXXXXX",
                "ActiveTrustedKeyGroups": {
                    "Enabled": false,
                    "Quantity": 0
                },
                "ActiveTrustedSigners": {
                    "Enabled": false,
                    "Quantity": 0
                },
                "AliasICPRecordals": [
                    {
                        "CNAME": "XXXX",
                        "ICPRecordalStatus": "APPROVED"
                    }
                ],
...

[ansibullbot]

cc @jillr @markuman @s-hertel @tremble @wilvk
click here for bot help

[tremble]

Thanks for digging into this.

I really like the use of boto3's pagination rather than something home-brew, however the decorator won't be able to do its thing without a minor tweak to the approach.

By catching ClientError and BotoCoreError within the methods the jittered backoff decorator never sees the rate limiting exceptions and thus can't retry the calls. To work around this I usually move just the pagination into a dedicated method, which can be wrapped, and the rest of the function (exception handling and all) can be done similar to the PR.

[tremble]

A minor nit in the changelog, but otherwise LGTM

[markuman]

LGTM

[ansible-zuul]

LGTM!