Update nexus commands.yml for docs gen

[prasek]

What was changed

• Updated commands.yml to address feedback on:
  • add temporal cli docs for nexus endpoints documentation#3149 (comment)
• Intended for use with the following, but also is fine to merge standalone
  • Improved docs gen #691
  • Enhanced docs gen to more closely match existing docs (legacy) #692

See this branch for the combined approach with all PRs merged in.

Why?

To create CLI docs for Nexus.

Checklist

1. How was this tested:

• go run ./temporalcli/internal/cmd/gen-docs
• also tested with the combined appraoch
  • copied generated docs (or subset) to temporalio/documentation
  • yarn start
  • verified via http://localhost:3000/

Ran go test ./...

Tested locally with:

go run ./cmd/temporal operator nexus endpoint create --name myendpoint --target-namespace my-target-namespace --target-task-queue my-handler-task-queue --description '## Sales Services
Workflow'\''s to support Customer-to-Order generation.

## other
stuff
'

2. Any docs updates needed?

• overall docs gen needs more alignment with the existing docs, but that is out of scope for these Nexus changes
• will update add temporal cli docs for nexus endpoints documentation#3149 with cherry picked generated content from the combined approach .

[yuandrew]

It doesn't seem right that this is the same description for overlap-policy, schedule-id, and schedule-configuration

[prasek]

The option-set description is a new field added for option-set usages in the the combined approach, where it would show up as follows:

Until the the combined approach lands this field is not used.

Note the main purpose is to to see where divergent option descriptions are used (in commands or option-sets) in the generated cmd-options.mdx that collate on the various option descriptions under a given option name across command and option set usages.

After discussion with @yuandrew it's likely these would just be used for linting rules as we're moving away from cmd-options.mdx as it doesn't scale very well.

Given that will remove all these option-set descriptions for now and we can revisit later.

[fairlydurable]

Ah, that's what you were going for. Sorry I was so confused. Thanks for the visual aid.

[yuandrew]

I'm not sure I see the benefit of option-set descriptions. They don't seem to add that much more information than what someone can glean from the option-set name

[prasek]

see comment above, it was for cmd-options.mdx generation where we wanted to emit a description of option usage:

• command usage or
• option-set usage

wanted the usage site be human friendly vs. the option-name. another option would be to find all commands that use the option-set and add those so all option usages are commands, but think removing description for now is more expedient, so will do that.

[fairlydurable]

Sounds good to me. Suggest a quick case-sensitive scan to inspect endpoint lowercase/uppercase.

[prasek]

feedback has been incorporated, think we're good to go.

@josh-berry @bergundy @fairlydurable

[josh-berry]

LGTM apart from one comment. Feel free to merge once addressed, no need to re-review.