feat: ensure endgame task comp registration + complete metadata bundle

[sicoyle]

Description

For each dapr release there is an endgame task to ensure that components are properly registered across contrib and dapr/dapr. I took a bit of time to create a new CLI with the other CLI cmds under /build-tools to automate this for myself (assigned this task), as well as for others. I also took the time to fix all the issues that I came across, cross referencing the docs. I have a list of components that need to be added to the docs. This took longer than one would hope; however, I noticed several components not registered properly in runtime, or in the docs, and several component types with no metadata.yaml files at all. I went ahead and added these metadata.yaml files myself as part of this endgame task. This PR is a first stab at fully automating this endgame task of ensuring component registration (and a complete metadata bundle) and does not hit every check box on my issue I created below, but again, is a great starting point and can be iterated on for future releases.

It's also nice bc i print out the counts, so we have accurate metrics in future and can also cross ref in the docs later on which more are missing than I found in my manual cross referencing

 go run . check-component-registrations 
Checking Dapr Component Registrations across runtime in dapr/dapr and components-contrib
========================================================================================

Checking conversation components...
Components in contrib: 9
Components registered in runtime: 9
All conversation components are properly configured

Checking state components...
Components in contrib: 28
Components registered in runtime: 28
All state components are properly configured

Checking pubsub components...
Components in contrib: 15
Components registered in runtime: 15
All pubsub components are properly configured

Checking secretstore components...
Components in contrib: 9
Components registered in runtime: 9
All secretstores components are properly configured

Checking bindings components...
Components in contrib: 50
Components registered in runtime: 50
All bindings components are properly configured

Checking configuration components...
Components in contrib: 3
Components registered in runtime: 3
All configuration components are properly configured

Checking lock components...
Components in contrib: 1
Components registered in runtime: 1
All lock components are properly configured

Checking cryptography components...
Components in contrib: 4
Components registered in runtime: 4
All cryptography components are properly configured

Checking name resolution components...
Components in contrib: 4
Components registered in runtime: 4
All nameresolution components are properly configured

Checking middleware components...
Components in contrib: 9
Components registered in runtime: 9
All middleware components are properly configured

Check completed!

I've fixed all issues; however, this is what my cli will output in the case of errs

Validation Results for state components:
Missing registrations: 4
  - postgresql.v1
  - postgresql.v2
  - azure.blobstorage.v1
  - azure.blobstorage.v2

Checking pubsub components...
Components in contrib: 14
Components registered in runtime: 17

Number of components in contrib and dapr/dapr do not match
Contrib: [jetstream redis servicebus.queues servicebus.topics eventhubs rabbitmq kubemq pubsub solace.amqp kafka snssqs pulsar rocketmq in-memory]

Dapr: [eventhubs in-memory kubemq mqtt servicebus.queues servicebusqueues pubsub kafka snssqs pulsar rabbitmq rocketmq solace.amqp servicebus.topics servicebus jetstream redis]

I also went through all metadata files and ensured we adhere to the types our metadata bundle accepts which are (component-metadata-schema.json):

 "type": {
          "type": "string",
          "enum": [
            "string",
            "number",
            "bool",
            "duration",
            "bytesize"
          ],
          "description": "Type of the property.\nIf this is empty, it's interpreted as \"string\"."
        },

Issue reference

#3948

fixes
#3946
#3945
#3943

Please reference the issue this PR will close: #[issue number]

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Extended the documentation
  • Created the dapr/docs PR:

Note: We expect contributors to open a corresponding documentation PR in the dapr/docs repository. As the implementer, you are the best person to document your work! Implementation PRs will not be merged until the documentation PR is opened and ready for review.

[sicoyle]

pls note that i did update these intentionally. This is specific to bindings gcp pubsub which is not stable or listed as any component type from what I saw. I updated this to match the existing stable gcp pubsub component type and so that way i can use the builtin gcp auth provider properly.

[WhitWaldo]

I wholly support this PR in its effort to ensure that the components-metadata-bundle.json file reflects accurate descriptions of what each of the supported components expect with all the schema validation.

Further, if this is something we can represent as a script that keeps these metadata outputs consistently up to date as part of the repository build/release pipeline, that would be fantastic for ensuring component parity with each tagged release!

[JoshVanL]

There are a large number of changes in this PR spanning multiple groups and concepts which makes it tricky to review. I this makes it higher risk that something is added which is incorrect or breaks something.

It has been a long standing issue that the metadata.yaml files should be generated, however I think this should come from a generi code type reflector which appropriate comment tag decoration of the input metadata.

As it stands, I don't want to move forward this all these additions where we rely on humans creating these files manually. Please can we at least split this PR into multiple PRs where each target a different change/metadata.yaml addition.

[JoshVanL]

All files should include a new line at EOF

[JoshVanL]

Where has this code come from?

[sicoyle]

#3949 (comment)

[JoshVanL]

Why this TODO?

[sicoyle]

I am open to suggestions on how to make this comment clearer.

As an approver in this repo, I take ownership seriously, and I use TODO comments intentionally to highlight areas that need improvement but are outside the current scope of my changes.

In this case, the comment came from a thorough review of each metadata.yaml file I personally touched in this PR. I noticed that many fields — particularly in alpha/beta components — are missing default values that would improve clarity and usability. While addressing that across the board felt out of scope for this specific task, I still wanted to surface it as something worth revisiting.

Happy to reword the comment or track it elsewhere if you have a suggestion

[sicoyle]

There are a large number of changes in this PR spanning multiple groups and concepts which makes it tricky to review. I this makes it higher risk that something is added which is incorrect or breaks something.

It has been a long standing issue that the metadata.yaml files should be generated, however I think this should come from a generi code type reflector which appropriate comment tag decoration of the input metadata.

As it stands, I don't want to move forward this all these additions where we rely on humans creating these files manually. Please can we at least split this PR into multiple PRs where each target a different change/metadata.yaml addition.

I split this effort out across component types for each PR :)

[sicoyle]

ready for review pls