Prepare customer-facing documentation for the API Gateway module

[nataliasitko]

Description
For the new modularization approach, we need documentation that is common for all the modules, e.g. general description (landing page), getting started, module configuration, etc.

AC

• Your audience is the end-user so the documentation must be written for them (not for the team that builds this module, or other SAP teams that wish to build a module, not for SRE, etc). Remember about the context. How much user knows by now (probably just high level knowledge about Kyma as a whole and that there are modules).
• The documentation must be consumable by the kyma-project.io home page (split into several information types/md files)
• Create a docs folder following the standard structure proposed in -> this template
• In each module's documentation include:
  • General description of the functionality (if the module is mandatory, mention it!)
  • Getting Started - instructions on how to use the module. The module docs must mention the prerequisite that the module must be enabled (don't explain 'how', just link to the generic document we (will) have on how to enable modules in Kyma (see Adjust the Get Started docs to modular approach)
  • Module configuration
  • Instructional documents (currently called "dev tutorials" and "operational guides") - must be isolated, i.e. no dependencies on other tutorials or modules. An example of a happy path for the user.
  • If needed, troubleshooting
  • Instructions on how to give feedback
  • CRD documentation (if needed)

Reasons

Prepare documentation for modular Kyma.

Assignees

@kyma-project/technical-writers

Attachments
kyma-project/kyma#16421

[triffer]

We should think about adding more examples to the documentation. I like how it is done In the Istio documentation, with examples for many of the embedded types, e.g. headers of HttpRoute.