Update AzureSearchAdminKey detector

[rgmz]

Description:

There are a number of problems with this detector. This Pr attempts to fix some of the glaring issues.

e.g.,

Verification issue: unexpected HTTP response status 400 | {"error":{"code":"","message":"Service name must only contain lowercase letters, digits or dashes, cannot start or end with or contain consecutive dashes and is limited to 60 characters."}}

Checklist:

• Tests passing (make test-community)?
• Lint passing (make lint this requires golangci-lint)?

[ahrav]

Single blocking change as it pertains to reformatting RawV2, otherwise LGTM!

[ahrav]

Changing the RawV2 value will break some enterprise customers, as we currently have secrets verified using the old key+service format. This change would orphan previously verified credentials and create duplicates. Is there a reason we can't continue supporting the old format?

[rgmz]

Is there a reason we can't continue supporting the old format?

Obviously you get the final say here, but #2128 has been a PITA for me and others using OSS.

TL;DR Most of the existing RawV2 values are suboptional because they smash together text (sometimes without a delimiter) and are devoid of context/keywords. This makes it impossible to programmatically re-construct and re-verify results.

[ahrav]

My guess is that when RawV2 was proposed, we didn't account for its visibility in OSS reporting. Wonder if we can find a solution that preserves readability for OSS while avoiding duplicates on the enterprise side?

This likely requires a broader discussion, and I think @zricethezav will have the most input, but I agree that combining multiple credentials makes them difficult to interpret and largely ineffective

[rgmz]

Seems like a new/different error introduced by the azure storage change. I'll take a look when I'm back on the computer.