Nomalised Azure frontdoor IDs

[terricain]

Fixes #8036

As of the 5th/6th of August 2020, the Azure FrontDoor response has become very inconsistent where case is used in resource IDs

Frontdoor JSON:

{
"name":"bink-frontdoor","id":"/subscriptions/00000000/resourcegroups/frontdoor/providers/Microsoft.Network/fro
  "Environment":"Production"
},"location":"Global","properties":{
  "provisioningState":"Succeeded","resourceState":"Enabled","backendPools":[
    {
      "id":"/subscriptions/00000000/resourcegroups/frontdoor/providers/Microsoft.Network/Frontdoors/bink-front
        "backends":[
          {
            "address":"api.snip","httpPort":80,"httpsPort":443,"priority":1,"weight":50,"backendHostHeader":"api.snip
          }
        ],"healthProbeSettings":{
          "id":"/subscriptions/00000000/resourcegroups/frontdoor/providers/microsoft.network/frontdoors/bink-f
        },"loadBalancingSettings":{
          "id":"/subscriptions/00000000/resourcegroups/frontdoor/providers/microsoft.network/frontdoors/bink-f
        },"resourceState":"Enabled"
      }
    },{
...
...
],"healthProbeSettings":[
  {
    "id":"/subscriptions/00000000/resourcegroups/frontdoor/providers/Microsoft.Network/Frontdoors/bink-front
      "intervalInSeconds":120,"path":"/healthz","protocol":"Https","resourceState":"Enabled","enabledState":"Enabled","healthProbeMethod
    }
  },{
    "id":"/subscriptions/00000000/resourcegroups/frontdoor/providers/Microsoft.Network/Frontdoors/bink-front
      "intervalInSeconds":120,"path":"/api/health","protocol":"Https","resourceState":"Enabled","enabledState":"Enabled","healthProbeMet
    }
  }
],"frontendEndpoints":[

So when processing the backend pools, the provider uses the lowercase ids to look up the healthProbeSettings which use mixed case ids

Am not super familiar with the AzureRM provider so there might be something I'm missing but these changes seem to fix the issues I am seeing.

[terricain]

Having investigated further, it seems when AFD resources are updated in the Azure portal, they then have a lowercase ID. If the ID checking was case-insensitive this would mean that its not a problem.

[tombuildsstuff]

hey @terrycain

Thanks for this PR - apologies for the delayed review here

Taking a look through whilst this is one approach to solving the problem - unfortunately where these ID's are passed around these would be subject to unintentional changes between Terraform runs (should the API be updated again). As such whilst I'd like to thank you for this contribution I'm going to close this in favour of #8146 which solves this problem and rewrites the ID's such that they are consistent/can be relied on - until the API is fixed.

Thanks!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!