IGNITE-27842 Remove redundant IgniteExperimental annotations (#12739)

(cherry picked from commit 5e193b6)

Author: timoninmaxim

docs/_docs/SQL/JDBC/jdbc-driver.adoc

@@ -176,13 +176,6 @@ include::{javaFile}[tags=multiple-endpoints, indent=0]
 
 === Partition Awareness [[partition-awareness]]
 
-[WARNING]
-====
-[discrete]
-Partition awareness is an experimental feature whose API or design architecture might be changed
-before a GA version is released.
-====
-
 Partition awareness is a feature that makes the JDBC driver "aware" of the partition distribution in the cluster.
 It allows the driver to pick the nodes that own the data that is being queried and send the query directly to those nodes
 (if the addresses of the nodes are provided in the driver's configuration). Partition awareness can increase average

docs/_docs/SQL/sql-calcite.adoc

@@ -20,8 +20,6 @@ Apache Calcite is a dynamic data management framework, which mainly serves for m
 
 The current H2-based SQL engine has a number of fundamental limitations of query execution in a distributed environment. To address these limitations, a new SQL engine was implemented. The new engine uses tools provided by Apache Calcite for parsing and planning queries. It also has a new query execution flow.
 
-CAUTION: The Calcite-based query engine is currently in beta status.
-
 == Calcite Module Libraries
 
 To use a Calcite-based engine, please make sure that the Calcite module libraries are in a classpath.

docs/_docs/SQL/sql-introduction.adoc

@@ -22,9 +22,7 @@ You can interact with Ignite as you would with any other SQL enabled storage by
 
 Internally, SQL tables have the same data structure as link:data-modeling/data-modeling#key-value-cache-vs-sql-table[key-value caches]. It means that you can change partition distribution of your data and leverage link:data-modeling/affinity-collocation[affinity colocation techniques] for better performance.
 
-Ignite's default SQL engine uses H2 Database to parse and optimize queries and generate execution plans, but also the Apache Calcite-based SQL engine can be enabled to execute queries.
-
-WARNING: Apache Calcite-based SQL engine is an experimental feature. For more information, see the link:SQL/sql-calcite[Calcite-based SQL engine, window=_blank] section.
+Ignite's default SQL engine uses H2 Database to parse and optimize queries and generate execution plans, but also the Apache Calcite-based SQL engine can be enabled to execute queries. For more information about Apache Calcite-based SQL engine, see the link:SQL/sql-calcite[Calcite-based SQL engine, window=_blank] section.
 
 == Distributed Queries
 

docs/_docs/key-value-api/using-cache-queries.adoc

@@ -121,13 +121,6 @@ include::code-snippets/cpp/src/scan_query.cpp[tag=set-local,indent=0]
 
 == Executing Index Queries
 
-[WARNING]
-====
-[discrete]
-Experimental API. Introduced since Apache Ignite 2.12. Only Java API is supported. Please send your questions and bug reports
-to user@ignite.apache.org.
-====
-
 Index queries work over distributed indexes and retrieve cache entries that match the specified query. `QueryCursor`
 delivers sorted cache entries by the order defined for queried index. `IndexQuery` can be used if a low amount of data
 matches filtering criteria. For such cases, `ScanQuery` usage is not optimal: it firstly extracts all cache entries and

docs/_docs/monitoring-metrics/performance-statistics.adoc

@@ -14,8 +14,6 @@
 // limitations under the License.
 = Performance Statistics
 
-WARNING: This feature is experimental and may change in future releases.
-
 == Overview
 
 Ignite provides a built-in tool for cluster profiling.

docs/_docs/monitoring-metrics/system-views.adoc

@@ -14,8 +14,6 @@
 // limitations under the License.
 = System Views
 
-WARNING: The system views are an experimental feature and can be changed in future releases.
-
 Ignite provides a number of built-in SQL views that contain information about cluster nodes and node metrics.
 The views are available in the SYS schema.
 See the link:SQL/schemas[Understanding Schemas] page for the information on how to access a non-default schema.

docs/_docs/monitoring-metrics/tracing.adoc

@@ -16,8 +16,6 @@
 
 :javaFile: {javaCodeDir}/Tracing.java
 
-WARNING: This feature is experimental.
-
 A number of APIs in Ignite are instrumented for tracing with OpenCensus.
 You can collect distributed traces of various tasks executed in your cluster and use this information to diagnose latency problems.
 
@@ -82,12 +80,6 @@ The following sections describe the two ways of enabling trace sampling.
 === Using Control Script
 
 Go to the `{IGNITE_HOME}/bin` directory of your Ignite installation.
-Enable experimental commands in the control script:
-
-[source, shell]
-----
-export IGNITE_ENABLE_EXPERIMENTAL_COMMAND=true
-----
 
 Enable tracing for a specific API:
 

docs/_docs/net-specific/net-platform-cache.adoc

@@ -14,8 +14,6 @@
 // limitations under the License.
 = .NET Platform Cache
 
-CAUTION: Experimental API
-
 Ignite.NET provides an additional layer of caching in the link:https://docs.microsoft.com/en-us/dotnet/standard/clr[CLR] heap. The platform cache keeps a deserialized copy of every cache entry that is present on the current node, thus greatly improving cache read performance at the cost of increased memory usage.
 
 [NOTE]

docs/_docs/services/services.adoc

@@ -312,8 +312,6 @@ an issue for real jobs like working with a DB or a cache.
 
 == Service Middleware
 
-WARNING: This feature is experimental and may change in future releases.
-
 [CAUTION]
 ====
 This feature may affect performance of service execution.

docs/_docs/starting-nodes.adoc

@@ -154,8 +154,6 @@ In this case, do not remove the nodes from the baseline topology.
 
 TODO: is this section valid for ignite?
 
-WARNING: This feature is experimental.
-
 When you simultaneously stop more nodes than the number of partition backups, some partitions may become unavailable to the remaining nodes (because both the primary and backup copies of the partition happen to be on the nodes that were shut down).
 For example, if the number of backups for a cache is set to 1 and you stop 2 nodes, there is a chance that both the primary and backup copy of a partition becomes unavailable to the rest of the cluster.
 The proper way of dealing with this situation is to stop one node, rebalance the data, and then wait until the rebalancing is finished before stopping the next node, and so on.