Add resource_id() extension method to Secrets

[heaths]

Parsing the name anv version from the resource ID (URL) is something we do across other Azure SDK languages and makes the API much more user-friendly. It's common to need to parse the name and version from a secret (or key or certificate) and pass into subsequent calls.

[heaths]

@RickWinter @JeffreyRichter I think we really need to take this one. We have similar utilities in our public APIs for most (all?) other Azure SDK languages because parsing the name and version out of a resource ID (URL) is often necessary to pass back into the client. This is also a good example of how service partners add value to their otherwise generated crates.

/cc @chlowell @jackrichins

[heaths]

As an example, instead of devs having to write code like this (or even less concise, which is likely for people newer to the language):

https://github.com/Azure/azure-sdk-for-rust/pull/2051/files#diff-e68c23fe7f799586bbbcaf760ba0cd25ac804e07b08c0c4519192f0ae3d00a2aR47-R56

They can simply write:

let id = secret.resource_id()?;
let secret = client.get_secret(id.name, id.version.unwrap_or_default(), None).await?;

[JeffreyRichter]

I'm OK with this in concept. For Azure Storage, all languages should have an equivalent of this type: https://pkg.go.dev/github.com/Azure/azure-sdk-for-go/sdk/storage/azblob#URLParts which has a ParseURL function.
This functionality was NOT put on the client on purpose. URLs (not clients) are passed between machines and may be manipulated without ever creating a client. So, given any Blob/KeyVault URL, you can parse it to get its interesting parts. A client should not have to be constructed first.

That being said, if a "convenience" function were put on a client to wrap this no-client-required functionality, I think that would be OK. In Go, we did not do this for all the various Blob clients.

[heaths]

Hanging it off a resource as an "extension method" makes sense in this case. It's not associated with a client either.

For Storage I could see something like Go's (/cc @vincenttran-msft) but Key Vault really only needs to expose the name and optional version. That said, I could get behind the "parts" nomenclature as a general rule of thumb. In most other languages for Key Vault we called this something like KeyVaultSecretIdentifier:

• https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/keyvault/Azure.Security.KeyVault.Secrets/src/KeyVaultSecretIdentifier.cs
• https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/keyvault/azure-security-keyvault-secrets/src/main/java/com/azure/security/keyvault/secrets/models/KeyVaultSecretIdentifier.java#L19
• https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/keyvault/keyvault-secrets/src/identifier.ts#L9
• https://github.com/Azure/azure-sdk-for-python/blob/83c337d41016527e0ac46231b488fdbdd2e09a07/sdk/keyvault/azure-keyvault-secrets/azure/keyvault/secrets/_models.py#L249

I'll name the getters the same and expose the vault URI but I think the extension method approach here is more idiomatic. In hindsight, I don't know why I didn't do that for .NET.

[heaths]

It'd be great to return a bunch of borrowed &str slices but the fact that constructing a url::Url takes ownership of the string - along with other problems in the past couple weeks - I opened #2053. This would allow cheaper parsing and less allocations for something like this.

[heaths]

I turned the source_id (nee id) and vault_url (new) into owned Strings because we don't really intend customers to do anything with them as Urls. If they really need a Url from it they can parse it into one, but there are really no supported scenarios for this for callers of this crate. The endpoint parameter - the vault_url here - name, and version parameters are all &str slices.

/cc @chlowell