fix: metadata capitalization

[sicoyle]

Description

We currently have consumerGroup, consumerID, and consumerId metadata fields on components. I think we should remove the consumerId metadata field as the capitalization difference is confusing, and there are very few components with this capitalization, so I'm wondering if this is an oversight and is fine to be corrected. I know that we do not strive for consistency in naming just for name sake, but I do think we should strive for capitalization consistency on fields with the same name across the board.

Issue reference

We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.

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 issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

[ItalyPaleAle]

All our fields are case-insensitive. If you want to update the metadata.yaml and the docs, that's all that needs to change :)

[berndverst]

And additionally, keep in mind that metadata.yaml is not what controls the accepted values - this is just documentation.

Our Kit/Decode Metadata function which is based on mitchellh/mapstructure uses the WeakDecode function which accepts any casing. There are several other convenience features, which is why all metadata should always be specified as struct tags and then decoded using this special function.

Also FYI, consumerID is a special metadata which actually is NOT defined in components-contrib. This is hardcoded in Dapr runtime, so you might need to verify in that repo what casing is accepted. Unlike in contrib, they don't use our metadata handling code in runtime.

[sicoyle]

ahh, okay. Docs do reflect the changes I'm making here, so that works out great and will require no doc updates: https://docs.dapr.io/reference/components-reference/supported-pubsub/setup-azure-eventhubs/

[berndverst]

And additionally, keep in mind that metadata.yaml is not what controls the accepted values - this is just documentation.

Our Kit/Decode Metadata function which is based on mitchellh/mapstructure uses the WeakDecode function which accepts any casing. There are several other convenience features, which is why all metadata should always be specified as struct tags and then decoded using this special function.

Also FYI, consumerID is a special metadata which actually is NOT defined in components-contrib. This is hardcoded in Dapr runtime, so you might need to verify in that repo what casing is accepted. Unlike in contrib, they don't use our metadata handling code in runtime.