Rename CommandType to Name on resource command types

[JamesNK]

Description

Feedback from #6295 (comment).

Note that this is a source breaking change for people who have implemented the proto when they update the proto the identifer will change name. It's not a wire breaking change because the field id (1 in this case) is the same.

@joperezr Where should the commandType -> name breaking change be communicated? The model API is new in 9.0 so I believe can change at this point without breaking change notification.

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire-docs issue:
  • No

[drewnoakes]

Looks fine, other than compile error in tests. I think "Id" would be a better term as it indicates the uniqueness requirement more so than "Name".

[DamianEdwards]

I think we need to do regular breaking change notifications as we changed this after the rc.

[JamesNK]

I prefer name because resources have a name, and endpoints have a name. Command names would be consistent.

And I think name makes more sense because the value is being provided by the user. Id feels more appropriate if the value is auto-generated.

[JamesNK]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[davidfowl]

It turns out we shipped commands in the resource server protocol so this change breaks ACA and we need to either revert all of it, or deprecate the old fields and add the new fields