Register storage_account as second name for storage metricset

[narph]

What does this PR do?

Register storage_account as second name for storage metricset
Conclusion for #28284

Why is it important?

Register storage_account as second name for storage metricset
Conclusion for #28284

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Related issues

Ex. record:

 "_source" : {
          "@timestamp" : "2021-10-14T15:24:00.000Z",
          "ecs" : {
            "version" : "1.12.0"
          },
          "host" : {
            "os" : {
              "version" : "10.0",
              "family" : "windows",
              "name" : "Windows 10 Pro",
              "kernel" : "10.0.19041.1288 (WinBuild.160101.0800)",
              "build" : "19041.1288",
              "type" : "windows",
              "platform" : "windows"
            },
            "id" : "bc395ab9-1a1a-4312-ad0b-a05cceaf78f1",
            "name" : "DESKTOP-K76UDQL",
            "ip" : [
              "2a02:a446:f25b:1:558d:72b2:74b6:7c67",
              "2a02:a446:f25b:1:50a1:b79:2bba:2ece",
              "fe80::558d:72b2:74b6:7c67",
              "192.168.2.34",
              "fe80::f09a:4481:bc48:e3e3",
              "169.254.227.227",
              "fe80::d135:57b1:9b7f:e10a",
              "169.254.225.10",
              "fe80::6901:1ee0:60dd:c986",
              "169.254.201.134",
              "fe80::fc98:6ed8:6d25:3d98",
              "169.254.61.152",
              "fe80::9cbc:1ebb:76b9:784a",
              "192.168.208.1",
              "fe80::3510:7ca8:de4e:3277",
              "172.23.16.1"
            ],
            "mac" : [
              "cc:48:3a:b9:87:c0",
              "9c:b6:d0:3e:a8:c4",
              "9e:b6:d0:3e:a8:c4",
              "ae:b6:d0:3e:a8:c4",
              "28:c2:1f:52:ff:bf",
              "00:15:5d:de:e2:d2",
              "00:15:5d:63:ae:f8"
            ],
            "hostname" : "DESKTOP-K76UDQL",
            "architecture" : "x86_64"
          },
          "agent" : {
            "version" : "8.0.0",
            "ephemeral_id" : "0a3179f5-f12d-4ece-b072-b2c315989223",
            "id" : "cc86e133-43d5-4170-855d-caa094862aa1",
            "name" : "DESKTOP-K76UDQL",
            "type" : "metricbeat"
          },
          "service" : {
            "type" : "azure"
          },
          "cloud" : {
            "region" : "westeurope",
            "provider" : "azure"
          },
          "event" : {
            "dataset" : "azure.storage_account",
            "module" : "azure",
            "duration" : 34640434800
          },
          "metricset" : {
            "name" : "storage_account",
            "period" : 300000
          },
          "azure" : {
            "subscription_id" : "70bd6e77-4b1e-4835-8896-db77b8eef364",
            "dimensions" : {
              "response_type" : "Success"
            },
            "storage_account" : {
              "transactions" : {
                "total" : 0
              }
            },
            "timegrain" : "PT5M",
            "namespace" : "Microsoft.Storage/storageAccounts",
            "resource" : {
              "type" : "Microsoft.Storage/storageAccounts",
              "group" : "obs-infrastructure",
              "name" : "urcbyscmrkbygsawinvm",
              "id" : "/subscriptions/70bd6e77-4b1e-4835-8896-db77b8eef364/resourceGroups/obs-infrastructure/providers/Microsoft.Storage/storageAccounts/urcbyscmrkbygsawinvm"
            }
          }
        },
        "sort" : [
          1634225040000
        ]
      }

[mergify]

This pull request does not have a backport label. Could you fix it @narph? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v./d./d./d is the label to automatically backport to the 7./d branch. /d is the digit

NOTE: backport-skip has been added to this pull request.

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2021-10-15T10:56:28.547+0000

• Duration: 103 min 48 sec

• Commit: 87ec850

Test stats 🧪

Test	Results
Failed	0
Passed	9549
Skipped	2537
Total	12086

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate the packages and run the E2E tests.

• /beats-tester : Run the installation tests with beats-tester.

[elasticmachine]

Pinging @elastic/integrations (Team:Integrations)

[botelastic]

This pull request doesn't have a Team:<team> label.

[jsoriano]

Do we want to document this or show some deprecation warning in the old name?

[narph]

no deprecation, I don't plan to change the name, just want to remove the pipeline in the future

[jsoriano]

So are both metricsets going to stay forever in beats?

[jsoriano]

So are both metricsets going to stay forever in beats?

[narph]

@jsoriano

So are both metricsets going to stay forever in beats?

Are they considered as 2 metricsets? I assumed it will just be one metricset with 2 registered names. I do not have any close future plans to replace the name and I was thinking that adding the deprecation message in the logs might push some users to move to the new naming but dashboards and docs do not support that.
Do you expect any potential issues here?

[jsoriano]

So are both metricsets going to stay forever in beats?

Are they considered as 2 metricsets?

This is an almost metaphysical question 😄

I assumed it will just be one metricset with 2 registered names. I do not have any close future plans to replace the name and I was thinking that adding the deprecation message in the logs might push some users to move to the new naming but dashboards and docs do not support that.
Do you expect any potential issues here?

If both names are going to stay by now I don't see any problem. Only that if we plan to remove the old registered name at some point we should warn users. If we don't plan to remove it, all good.