feat: add ability to exclude some operations from security-defined rule

[tatomyr]

What/Why/How?

Adds the ability to exclude some paths or particular operations from the security-defined rule.

Here's an example:

redocly.yaml

rules:  
  security-defined: 
    exceptions:
      - path: /partially-skipped
        methods:
          - get
      - path: /fully-skipped

openapi.yaml

openapi: 3.1.0
paths:
  /partially-skipped:
    get:
      description: Skipped.
    post: 
      description: Has security.
      security: []
    delete: 
      description: Should have security defined!
  /fully-skipped:
    get:
      description: Skipped.
    post: 
      description: Skipped.
  /required:
    get: 
      summary: Should have security defined!

The ouput:

Reference

Resolves: #1569

Testing

Screenshots (optional)

Check yourself

• Code changed? - Tested with redoc/reference-docs/workflows (internal)
• All new/updated code is covered with tests
• New package installed? - Tested in different environments (browser/node)

Security

• Security impact of change has been considered
• Code follows company security practices and guidelines

[changeset-bot]

🦋 Changeset detected

Latest commit: 3aa0951

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@redocly/openapi-core	Minor
@redocly/cli	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
redocly lint packages/core/src/benchmark/benches/rebilly.yaml	988.5 ± 72.7	930.2	1178.6	1.01 ± 0.08
redocly-next lint packages/core/src/benchmark/benches/rebilly.yaml	979.2 ± 20.3	959.3	1028.8	1.00

[github-actions]

Coverage report

St.❔	Category	Percentage	Covered / Total
🟡	Statements	77.26%	4485/5805
🟡	Branches	67.57%	2479/3669
🟡	Functions	70.94%	747/1053
🟡	Lines	77.45%	4218/5446

Test suite run success

738 tests passing in 102 suites.

Report generated by 🧪jest coverage report action from 3aa0951

[RomanHotsiy]

LGTM 👍

[lornajane]

Looking at #1569 , it would be better to have the users declare the security as open than to omit it - the benefit to the user is that the good practice is part of their OpenAPI description so will apply throughout the lifecycle and all tools.

[RomanHotsiy]

Looking at #1569 , it would be better to have the users declare the security as open than to omit it - the benefit to the user is that the good practice is part of their OpenAPI description so will apply throughout the lifecycle and all tools.

Yes! Definitely it's better and that's why we have this rule. Unfortunately there are cases when it can't be done due to various reasons (like not controlling the openapi description directly multiplied by 100s of APIs). So it's good to have some way for exceptions.