Improve naming of per-format rules sections

[lornajane]

Is your feature request related to a problem? Please describe.

Most users of Redocly CLI list rules under rules but as we see more customers using multiple API formats in their projects, we need to document the per-format rules config entries so that different formats can be linted using different rulesets. The per-format rules config entries currently are:

• oas2Rules
• oas3_0Rules
• oas3_1Rules
• async2Rules
• async3Rules
• arazzoRules

(equivalents exist for *Preprocessors and *Decorators)

Proposal: rename these config settings to something that fits our config naming scheme

In an ideal world, we could offer something like this:

rules:
  openapi-30:
    security-defined: warn
  arazzo-10:
    parameters-unique: error

Describe alternatives you've considered

Just make the config entry names more sane and leave them at the top level:

• oas2Rules -> rules-openapi-20
• oas3_0Rules -> rules-openapi-30
• oas3_1Rules -> rules-openapi-31
• async2Rules -> rules-asyncapi-26
• async3Rules -> rules-asyncapi-30
• arazzoRules -> rules-arazzo-10

Additional context

From a discussion with @DmitryAnansky and @tatomyr about how to thoroughly support and document our multi-format linting features.

[tatomyr]

I vote for the top-level, but I don't like naming like openapi-30... Maybe openapi-3-0 will work better?

[lornajane]

@adamaltman or @RomanHotsiy could you comment on the requested renaming?

[RomanHotsiy]

It sounds good. I agree with @tatomyr though on the naming, I prefer openapi-3-0 or we can even do openapi-3.0. Both yaml and json support keys with dots.

[tatomyr]

@RomanHotsiy It looks much nicer with dots. The only issue is that I vaguely remember we had some problems with parsing features.openapi. Or am I wrong?

[lornajane]

I think it would probably work, but it's confusing to use dots inside a yaml key IMO, just because there's a convention of using it as a separator. For example info.description , we use this pattern ourselves in Redoc rendering too. So I discarded the dot and thought that the extra dash wasn't needed with every version being one major digit and one minor one. Happy to compromise on the two-dash format though!

Will we refactor this throughout the code, or as an alias for parsing the config in? We use this type of pattern in plugins too (as well as internally)

[tatomyr]

Will we refactor this throughout the code, or as an alias for parsing the config in?

For me, it doesn't make much sense to refactor it deeply, especially taking into account that we will have to use some artificial names for the variables anyway.