Resource IDs: support for parsing Data Plane IDs

[tombuildsstuff]

The Resource ID Parser (that is, the resourceids.Parse.Parse function) assumes that we're parsing an ARM-style Resource ID (although these also work for Microsoft Graph), e.g.

/providers/Microsoft.Blah
/subscriptions/XXX
/subscriptions/XXX/resourceGroups/XXX

However most Data Plane resources use Resource IDs in the format:

https://{accountName}.{domainSuffix}/{segment}/{segment}

Which means these have to be defined by hand today - and means that these don't use the new Resource ID Parser logic, which we'll want going forwards.

---

Note

Some APIs also (incorrectly) return:

https://{accountName}.{domainSuffix}:{port}/{segment}/{segment}

Note: when the protocol is https and a value for port of 443 is specified, we should be able to trim this from the Domain Suffix for normalization purposes.

---

As such we're going to need to extend the Resource ID Parser - and the Resource ID Segment types to support parsing Resource IDs in this format.

Whilst the examples above - and the majority of Resource IDs in this format use https as the protocol, we have some instances in AzureRM where it could be useful to validate additional protocols too (e.g. tcp://).

As such I suspect we're going to need to introduce 3 new Resource ID Segment types here:

• ProtocolResourceIdSegment - for parsing the protocol in the format {protocol}:// - e.g. https from https://.
• AccountNameResourceIdSegment - for parsing the Account Name from the hostname - e.g. account1 from account1.blob.storage.azure.com. In this instance we can assume a domain name in the format {account}.{domainSuffix}.
• DomainSuffixResourceIdSegment - for parsing the domain suffix from the hostname - e.g. blob.storage.azure.com from account1.blob.storage.azure.com. In this instance we can assume a domain name in the format {account}.{domainSuffix}.

In addition the Resource ID format functions (.ID() and .String()) will need to be updated to account for this at the same time.

Once this work is completed, Pandora also needs to become aware of the new Resource ID Segment Types - however this can be done in two stages:

1. Adding the new Constants to Pandora (Importer, Data API and SDK).
2. Open an issue to track implementing full support for the new Resource ID Segment Types - which'll be needed for supporting Data Plane functionality in Pandora.

[manicminer]

Suggest we consider keeping the segment types generic enough to support nested subdomains, even if it's just a slice of subdomain names. I don't think we need this now but it could cater for a future where mycontainer.myaccount.azureservice.com could arise, and may make it easier to pull out the subdomain type for the likes of Storage.