docs links fixes (#6123)

CONTRIBUTING.md

@@ -52,18 +52,18 @@ When writing documentation please follow these instructions:
     ```
     [main configuration file](./Common#configuration-areas) 
     ```
-* all links to `https://nussknacker.io/documentation/`, but other than `Documentation` section in that page, e.g. to `About` or `Quickstart` sections: 
+* all links to `https://nussknacker.io/documentation/`, but other than `Documentation` section in that page, e.g. to `Quickstart` sections: 
   * should **not** point to `md` or `mdx` files
   * should **not** be relative
     
   example of correct link:
     ```
-    [Components](/about/GLOSSARY#component)
+    [Components](/quickstart/GLOSSARY#component)
     ```
   example of incorrect links:
     ```
-    [Components](/about/GLOSSARY.md#component)
-    [Components](../about/GLOSSARY#component)
+    [Components](/quickstart/GLOSSARY.md#component)
+    [Components](../quickstart/GLOSSARY#component)
     ```
 ### Automatic Screenshots Updates in Documentation
 

README.md

@@ -35,9 +35,9 @@ An essential part of Nussknacker is a visual design tool for decision algorithms
 
 The way the data are processed and features available depend on the processing mode and engine used. 
 
-Nussknacker supports three [processing modes](https://nussknacker.io/documentation/about/ProcessingModes/): streaming, request-response and batch (planned in version 1.16). In streaming mode, Nussknacker uses Kafka as its primary interface: input streams of data and output streams of decisions. In request-response mode, it exposes HTTP endpoints with OpenAPI definitions. 
+Nussknacker supports three [processing modes](https://nussknacker.io/documentation/docs/about/ProcessingModes/): streaming, request-response and batch (planned in version 1.16). In streaming mode, Nussknacker uses Kafka as its primary interface: input streams of data and output streams of decisions. In request-response mode, it exposes HTTP endpoints with OpenAPI definitions. 
 
-There are two engines to which scenarios can be deployed: Flink and Light. Check out [this document](https://nussknacker.io/documentation/about/engines/) to understand which of the two fits fits your use case better. 
+There are two engines to which scenarios can be deployed: Flink and Light. Check out [this document](https://nussknacker.io/documentation/docs/about/engines/) to understand which of the two fits fits your use case better. 
 
 ## Why Nussknacker
 
@@ -46,11 +46,11 @@ Nussknacker promises to make developing and deploying real-time decision algorit
 We discovered that several factors heavily influence the development of algorithms that work with real-time data, including expectations placed on the tools used:
 - **Domain experts** - often, these are domain experts who conceptualize the algorithms, and the expertise required is very domain specific. Without proper tools for converting algorithms to code, domain experts have to delegate this work to programmers who are proficient in multiple tools, programming languages, and technologies. This approach costs money and takes time. With Nussknacker, domain experts build the algorithm from prefabricated blocks. The trick is to make these prefabricated blocks infinitely flexible to allow for any data transformation and flow control condition. Nussknacker achieves this by using [SpEL](https://nussknacker.io/documentation/docs/scenarios_authoring/Intro/#spel), an easy-to-learn expression language.
 - **Experimentation** - the algorithms may require a lot of experimentation before one gets them right. If so, the iteration time required to implement a change, deploy it, and see the result should be in single minutes if not seconds. With Nussknacker, non-technical users can achieve iteration time below one minute.
-- **Productivity** - if low-code solutions want to be considered tools rather than toys, they must offer features available in professional developer toolkits. Nussknacker Designer has built-in [syntax checking, code completion ](https://nussknacker.io/documentation/about/KeyFeatures/#smart-code-suggestions-and-validation), versioning, [debugging, and testing support](https://nussknacker.io/documentation/docs/next/scenarios_authoring/TestingAndDebugging/).
+- **Productivity** - if low-code solutions want to be considered tools rather than toys, they must offer features available in professional developer toolkits. Nussknacker Designer has built-in [syntax checking, code completion ](https://nussknacker.io/documentation/docs/about/KeyFeatures/#smart-code-suggestions-and-validation), versioning, [debugging, and testing support](https://nussknacker.io/documentation/docs/next/scenarios_authoring/TestingAndDebugging/).
 - **Observability** - experimenting with algorithms requires insights going beyond pure technical metrics like throughput, Kafka topics lag, etc. Out of the box, Nussknacker comes with an integrated and ready-to-use monitoring subsystem which allows monitoring not only technical aspects of the running scenario but also its internal behavior - for example [events count](https://nussknacker.io/documentation/docs/next/scenarios_authoring/TestingAndDebugging/#watching-nodes-filtering-behaviour-with-counts) per scenario step. You will not need to spend developers' time on this functionality.
 - **Architecture** - last but not least, the fundamentals on which you build matter. Nussknacker  achieves exceptional throughput, horizontal scalability, resilience, and high availability through the use of tools and platforms known for their rock-solid architecture - Kafka, Flink, and Kubernetes, which handle all processing tasks.
 
-Check out [this document](https://nussknacker.io/documentation/about/KeyFeatures/) for a concise summary of Nussknacker features. 
+Check out [this document](https://nussknacker.io/documentation/docs/about/KeyFeatures/) for a concise summary of Nussknacker features. 
 
 
 ## Use cases
@@ -70,7 +70,7 @@ Nussknacker is typically used as a component of a larger system, but it can be u
 
 ## Where to learn more
 
-- [Typical deployment](https://nussknacker.io/documentation/about/TypicalImplementationStreaming/)
+- [Typical deployment](https://nussknacker.io/documentation/docs/about/typical%20implementation/Streaming/)
 - [Authoring scenarios with Nussknacker](https://nussknacker.io/documentation/docs/scenarios_authoring/Intro/) 
 - [Customer success story](https://nussknacker.io/case-studies/real-time-marketing-for-a-telecom-service-provider/)
 

designer/client/src/components/AddProcessForm.tsx

@@ -120,7 +120,7 @@ export function AddProcessForm({
                                 Processing mode defines how scenario deployed on an engine interacts with the outside world. Click here to
                                 <Link
                                     sx={{ cursor: "pointer", ml: 0.5 }}
-                                    href="https://nussknacker.io/documentation/about/ProcessingModes"
+                                    href="https://nussknacker.io/documentation/docs/about/ProcessingModes"
                                     target="_blank"
                                     rel="noopener noreferrer"
                                 >
@@ -201,7 +201,7 @@ export function AddProcessForm({
                                     To read more about engines,
                                     <Link
                                         sx={{ cursor: "pointer", ml: 0.5 }}
-                                        href="https://nussknacker.io/documentation/about/engines"
+                                        href="https://nussknacker.io/documentation/docs/about/engines"
                                         target="_blank"
                                         rel="noopener noreferrer"
                                     >

dockerhub/nussknacker-lite-runtime-app/README.md

@@ -10,7 +10,7 @@ latest-staging - developer build with latest, not released yet features
 
 # How to use
 
-This image is not designed to be used from command line at first place. The main purpose of it is to be used programmatically by [Nussknacker K8s Deployment Manager](https://nussknacker.io/documentation/about/engines/LiteArchitecture/).
+This image is not designed to be used from command line at first place. The main purpose of it is to be used programmatically by [Nussknacker K8s Deployment Manager](https://nussknacker.io/documentation/docs/about/engines/LiteArchitecture/).
 
 If you want to check it manually, the invocation will look like:
 ```

docs/LicenseInfo.md

@@ -7,7 +7,7 @@ All the **Nussknacker** code available on [GitHub](https://github.com/TouK/nussk
 
 ### Enterprise edition
 
-The [Nussknacker Enterprise](/about/NussknackerEnterprise) version is subject to different license terms. Contact [email protected] for more information. 
+The [Nussknacker Enterprise](about/NussknackerEnterprise) version is subject to different license terms. Contact [email protected] for more information. 
 
 Additionally, the ML Enricher enterprise component uses [JPMML-Evaluator](https://github.com/jpmml/jpmml-evaluator) library licensed under the BSD 3-Clause License reproduced below:
 

docs/developers_guide/Basics.md

@@ -1,6 +1,6 @@
 # Overview
 
-Please make sure you know common [Glossary](/documentation/about/GLOSSARY) and [SpEL](../scenarios_authoring/Spel.md) (especially the Data types section) before proceeding further. 
+Please make sure you know common [Glossary](../about/GLOSSARY) and [SpEL](../scenarios_authoring/Spel.md) (especially the Data types section) before proceeding further. 
 
 This part of the documentation describes various ways of customizing Nussknacker - from adding own Components to adding listeners for various Designer actions. 
 The main way of adding customizations to Nussknacker is [ServiceLoader](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/ServiceLoader.html) 
@@ -21,7 +21,7 @@ We also handle union types (again, similar to [Typescript](https://www.typescrip
 
 ## Components and ComponentProviders
 
-[Components](/about/GLOSSARY#component) are main method of customizing Nussknacker. Components are created by configured `ComponentProvider` instances. 
+[Components](../about/GLOSSARY#component) are main method of customizing Nussknacker. Components are created by configured `ComponentProvider` instances. 
 There are following types of components:
 - `SourceFactory`
 - `SinkFactory`

docs/installation_configuration_guide/Common.md

@@ -17,15 +17,15 @@ Details of K8s based configuration can be found in  [Nussknacker Helm chart docu
 
 Nussknacker configuration is divided into several configuration areas, each area addressing a specific aspect of using Nussknacker:
 
-* [Designer](/about/GLOSSARY#nussknacker-designer) configuration (web application ports, security, various UI settings, database),
+* [Designer](../about/GLOSSARY#nussknacker-designer) configuration (web application ports, security, various UI settings, database),
 * Scenario Types configuration, comprising of:
-  * [Model](/about/GLOSSARY#model) configuration.
+  * [Model](../about/GLOSSARY#model) configuration.
   * [Scenario Deployment](./ScenarioDeploymentConfiguration.md) configuration,
   * [Category](./DesignerConfiguration.md/#scenario-type-categories) configuration
 
-[Model](/about/GLOSSARY#model) configuration defines which components and which [Processing Mode](/about/ProcessingModes) will be available for the user. 
-[Scenario Deployment](./ScenarioDeploymentConfiguration.md) configuration defines how scenario using these components will be deployed on the [Engine](/about/engine).
-[Category](./DesignerConfiguration.md/#scenario-type-categories) defines who has access to the given combination of [Model](/about/GLOSSARY#model) and [Scenario Deployment](./ScenarioDeploymentConfiguration.md).
+[Model](../about/GLOSSARY#model) configuration defines which components and which [Processing Mode](../about/ProcessingModes) will be available for the user. 
+[Scenario Deployment](./ScenarioDeploymentConfiguration.md) configuration defines how scenario using these components will be deployed on the [Engine](../about/engine).
+[Category](./DesignerConfiguration.md/#scenario-type-categories) defines who has access to the given combination of [Model](../about/GLOSSARY#model) and [Scenario Deployment](./ScenarioDeploymentConfiguration.md).
 
 The Scenario Type is a convenient umbrella term that groups all these things. Diagram below presents main relationships between configuration areas.
 
@@ -69,7 +69,7 @@ scenarioTypes {"{"}  <br/>
 It is worth noting that one Nussknacker Designer may be used to work with multiple Scenario Types and allow user:
 
 * To use different set of components depending on the category
-* To deploy scenarios on different [Engines](/about/engine)
+* To deploy scenarios on different [Engines](../about/engines)
 
 See [development configuration](https://github.com/TouK/nussknacker/blob/staging/nussknacker-dist/src/universal/conf/dev-application.conf#L33) (used to test various Nussknacker features) for an example of configuration with more than one Scenario Type.                   
 

docs/installation_configuration_guide/ScenarioDeploymentConfiguration.md

@@ -5,12 +5,12 @@ sidebar_position: 3
 
 # Scenario Deployment configuration
 
-In order to deploy scenario on the given [Engine](/about/engines), you need to configure the deployment.
+In order to deploy scenario on the given [Engine](../about/engines), you need to configure the deployment.
 
-Deployment of a scenario is managed by Designer's extension called [Deployment Manager](/about/GLOSSARY#deployment-manager).
-To enable given [Deployment Manager](/about/GLOSSARY#deployment-manager) you need to place its jar package in the Designer's classpath.
-Nussknacker is distributed with three default [Deployment Managers](/about/GLOSSARY#deployment-manager) (`flinkStreaming`, `lite-k8s`, `lite-embedded`). Their jars are located in the `managers`
-directory. Depending on which [Deployment Manager](/about/GLOSSARY#deployment-manager) you've selected, you should provide parameters values for it specifically - see sections below to find out available parameters.
+Deployment of a scenario is managed by Designer's extension called [Deployment Manager](../about/GLOSSARY#deployment-manager).
+To enable given [Deployment Manager](../about/GLOSSARY#deployment-manager) you need to place its jar package in the Designer's classpath.
+Nussknacker is distributed with three default [Deployment Managers](../about/GLOSSARY#deployment-manager) (`flinkStreaming`, `lite-k8s`, `lite-embedded`). Their jars are located in the `managers`
+directory. Depending on which [Deployment Manager](../about/GLOSSARY#deployment-manager) you've selected, you should provide parameters values for it specifically - see sections below to find out available parameters.
 
 Section with `deploymentConfig` needs to be placed in the correct place in the Designer's configuration. Check [configuration areas](./Common.md#configuration-areas) to understand the structure of the configuration.
 
@@ -27,12 +27,12 @@ deploymentConfig {
 ```
 
 Parameters:
-- `type` parameter determines the type of the [Deployment Manager](/about/GLOSSARY#deployment-manager). Possible options are: `flinkStreaming`, `lite-k8s`, `lite-embedded`
+- `type` parameter determines the type of the [Deployment Manager](../about/GLOSSARY#deployment-manager). Possible options are: `flinkStreaming`, `lite-k8s`, `lite-embedded`
 - `engineSetupName` parameter is optional. It specifies how the engine will be displayed in the GUI. If not specified, default name will be used instead (e.g. `Flink` for `flinkStreaming` Deployment Manager).   
 
 ## Kubernetes native Lite engine configuration
 
-Please check high level [Lite engine description](https://nussknacker.io/documentation/about/engines/LiteArchitecture/#scenario-deployment) before proceeding to configuration details.
+Please check high level [Lite engine description](https://nussknacker.io/documentation/docs/about/engines/LiteArchitecture/#scenario-deployment) before proceeding to configuration details.
 
 Please note, that K8s Deployment Manager has to be run with properly configured K8s access. If you install the Designer in K8s cluster (e.g. via Helm chart) this comes out of the box. If you want to run the Designer outside the cluster, you have to configure `.kube/config` properly.
 

docs/installation_configuration_guide/model/ModelConfiguration.md

@@ -5,9 +5,9 @@ sidebar_position: 1
 # Model configuration
 
 Model definition is part of a scenario type definition. There can be multiple scenario types in one Nussknacker installation, consequently there will also be multiple model definitions in such a case. 
-Check [configuration areas](docs/installation_configuration_guide/Common.md#configuration-areas) to understand where Model configuration should be placed in the Nussknacker configuration. If you deploy to K8s using Nussknacker Helm chart, check [here](../ScenarioDeploymentConfiguration.md#overriding-configuration-passed-to-runtime) how to supply additional model configuration.
+Check [configuration areas](../Common.md#configuration-areas) to understand where Model configuration should be placed in the Nussknacker configuration. If you deploy to K8s using Nussknacker Helm chart, check [here](../ScenarioDeploymentConfiguration.md#overriding-configuration-passed-to-runtime) how to supply additional model configuration.
 
-Model defines how to configure [components](/about/GLOSSARY#component) and certain runtime behavior (e.g. error handling) for a given scenario type. Model configuration is processed not only at the Designer but also passed to the execution engine (e.g. Flink), that’s why it’s parsed and processed a bit differently: 
+Model defines how to configure [components](../../about/GLOSSARY#component) and certain runtime behavior (e.g. error handling) for a given scenario type. Model configuration is processed not only at the Designer but also passed to the execution engine (e.g. Flink), that’s why it’s parsed and processed a bit differently: 
 
 * Some Components can use a special mechanism which resolves and adds additional configuration during deployment, which is then passed to the execution engine. Such configuration is read and resolved only at the Designer. Example: OpenAPI enrichers need to read its definition from external sites - so e.g. Flink cluster does not have to have access to the site with the definition. 
 * There is additional set of defaults, taken from `defaultModelConfig.conf` if it exists on the classpath. The standard Nussknacker installation uses the one from [here](https://github.com/TouK/nussknacker/blob/staging/defaultModel/src/main/resources/defaultModelConfig.conf), installations using certain code customizations may use a different one.       
@@ -42,9 +42,9 @@ Nussknacker comes with a set of provided components. Some of them (e.g. `filter`
 predefined and accessible by default. Others need additional configuration - the most important ones are enrichers, where you have to set e.g. JDBC URL or external service address.
 
 Check Integration documentation for the details on how to configure the following components:
-- [OpenAPI](docs/integration/OpenAPI.md) Supports accessing external APIs directly from scenario 
-- [SQL](docs/integration/Sql.md)         Supports access to SQL database engines    
-- [Machine Learning](docs/integration/MachineLearning.md)         Infers ML models
+- [OpenAPI](../../integration/OpenAPI.md) Supports accessing external APIs directly from scenario 
+- [SQL](../../integration/Sql.md)         Supports access to SQL database engines    
+- [Machine Learning](../../integration/MachineLearning.md)         Infers ML models
 
 
 ### Configuration of component providers

docs/integration/KafkaIntegration.md

@@ -8,7 +8,7 @@ sidebar_position: 1
 
 To better understand how Nussknacker works with Kafka, it's recommended to read the following first:
 * [Kafka introduction](https://kafka.apache.org/intro)
-* [Role of Schema Registry](/about/TypicalImplementationStreaming/)
+* [Role of Schema Registry](../about/typical%20implementation/Streaming.md)
 * [Confluent Schema Registry](https://docs.confluent.io/platform/current/schema-registry/index.html)
 
 If you want to use Flink engine, this is also recommended: