Express Route Circuit (2020-05-01): creation eventual consistent

## Reproduce

1. Create an Express Route Circuit and wait till finish (via polling the operation url)
2. Delete it and wait till finish (via polling the operation url)
3. Create another Express Route Circuit with the same name and wait till finish (via polling the operation url)
4. Invoke a GET right after step 3, it returns 404.

Hence, clients can not rely on the polling result of the operation URL, but have to poll via GET until GET returns 200.

## The Sequence

**Create a express route circuit:**

PUT https://management.azure.com/subscriptions/0-0-0-0/resourceGroups/acctestRG-200715135929363936/providers/Microsoft.Network/expressRouteCircuits/acctest-erc-200715135929363936?api-version=2020-05-01
REQUEST

{

    "location": "eastus2",

    "properties": {

        "allowClassicOperations": false,

        "serviceProviderProperties": {

            "bandwidthInMbps": 50,

            "peeringLocation": "Silicon Valley",

            "serviceProviderName": "Equinix"

        }

    },

    "sku": {

        "family": "MeteredData",

        "name": "Standard_MeteredData",

        "tier": "Standard"

    },

    "tags": {

        "Environment": "production",

        "Purpose": "AcceptanceTests"

    }

}

RESPONSE

{

    "etag": "W/\"f1fe06f4-8be0-40f1-9538-87802fada321\"",

    "id": "/subscriptions/0-0-0-0/resourceGroups/acctestRG-200715135929363936/providers/Microsoft.Network/expressRouteCircuits/acctest-erc-200715135929363936",

    "location": "eastus2",

    "name": "acctest-erc-200715135929363936",

    "properties": {

        "allowClassicOperations": false,

        "allowGlobalReach": false,

        "authorizations": [],

        "circuitProvisioningState": "Disabled",

        "globalReachEnabled": false,

        "peerings": [],

        "provisioningState": "Updating",

        "resourceGuid": "fd7cd84f-d786-4358-a869-626458bd3dde",

        "serviceKey": "00000000-0000-0000-0000-000000000000",

        "serviceProviderProperties": {

            "bandwidthInMbps": 50,

            "peeringLocation": "Silicon Valley",

            "serviceProviderName": "Equinix"

        },

        "serviceProviderProvisioningState": "NotProvisioned"

    },

    "sku": {

        "family": "MeteredData",

        "name": "Standard_MeteredData",

        "tier": "Standard"

    },

    "tags": {

        "Environment": "production",

        "Purpose": "AcceptanceTests"

    },

    "type": "Microsoft.Network/expressRouteCircuits"

}

**Repeatedly poll the async operation URL, until:**

GET https://management.azure.com/subscriptions/0-0-0-0/providers/Microsoft.Network/locations/eastus2/operations/5bc6316f-611f-4b8f-aec0-b15298534811?api-version=2020-05-01

{

    "status": "Succeeded"

}

**Invoke a GET right after:**

GET https://management.azure.com/subscriptions/0-0-0-0/resourceGroups/acctestRG-200715135929363936/providers/Microsoft.Network/expressRouteCircuits/acctest-erc-200715135929363936?api-version=2020-05-01

{

    "error": {

        "code": "ResourceNotFound",

        "message": "The Resource 'Microsoft.Network/expressRouteCircuits/acctest-erc-200715135929363936' under resource group 'acctestRG-200715135929363936' was not found. For more details please go to https://aka.ms/ARMResourceNotFoundFix"

    }

}

Start with the reported Express Route Circuit API sequence for version 2020-05-01: create, poll the operation URL, delete, recreate, and immediately GET the resource. Compare the operation result with the GET response and determine what repository change or documented resolution is required; done when the eventual-consistency behavior has an agreed, verifiable resolution.

Written by the indexing model from the issue text.