Document handling of OpenApi media types in API Security

What does this MR do?

The change in the documentation is about the usage of OpenApi media types in API Security. API Security support specific media types and OpenApi document can provide any media type or none of the supported. Hence this leads to two possible outcomes:

1. A valid document with none of the supported media types
2. A valid document with multiple supported media types.

• API Security has been updated to throw an error when there are no supported media types. Previously, there was no error even though the document was valid.
• There are two new environment variables to allow users to specify which media types to use:
  • API Security has been updated to check flag OPENAPI_ALL_MEDIA_TYPES, when set to any value it uses all supported media types, otherwise, it will only use one supported media type. before the code change, it was using all supported media types.
  • API Security has been updated to check flag OPENAPI_MEDIA_TYPES. By default is disabled, and it gets enabled by setting it to any value. The expected value is a list of media types (e.g. application/json, application/xml, ... among others) where each media type is separated by colon (:), for instance application/json:application/xml. Once the environmental variable has been set, it defined which media types have to be used when generating requests.

Changes in the documentation are:

• Documents new environmental variable OPENAPI_ALL_MEDIA_TYPES and OPENAPI_MEDIA_TYPES
• Add an explanation of the new error message in troubleshoot section about error when there are media types in the OpenApi document but none of them are supported.
• Adds explanation about when to use new environmental variable OPENAPI_ALL_MEDIA_TYPES in OpenApi Specification section.
• Adds explanation about when to use new environmental variable OPENAPI_MEDIA_TYPES in OpenApi Specification section.

Related issues

• #333304 (closed)

Author's checklist

• [-] Consider taking the GitLab Technical Writing Fundamentals course.
• [-] Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• Ensure that the product tier badge is added to topic's h1.
• Request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

Review checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.
• Ensure a release milestone is set.