Update UCN docs about NS removal [CTT-1078] [v/5.6] (#2142)

Backport of #2140

The documentation currently does not mention the caveat for UCNs that
they cannot be removed at runtime; this PR addresses this.

Fixes https://hazelcast.atlassian.net/browse/CTT-1078

Co-authored-by: James Holgate <130981049+JamesHazelcast@users.noreply.github.com>

Author: github-actions[bot]

docs/modules/clusters/pages/ucn-dynamic-config.adoc

@@ -5,7 +5,7 @@
 
 {description}
 
-For example, you can use the dynamic configuration API to add or replace a specific namespace on a running cluster's configuration.
+For example, you can use the dynamic configuration API to add a namespace on a running cluster's configuration, or replace the resources for an existing namespace.
 
 NOTE: Before you can use {ucn}, you must enable it as described in the xref:clusters:ucn-enable.adoc[] topic.
 

docs/modules/clusters/pages/ucn-migrate-ucd.adoc

@@ -13,5 +13,4 @@ There are several differences between {ucd} and {ucn} that you must account for
 This means that resources deployed statically need to be referenceable by all members of the cluster. For more information, see xref:clusters:ucn-member-side.adoc[].
 * Resources deployed with {ucd} are added to the member classpath. In contrast, {ucn} introduces namespaces, which allows resources to be separated. This separation allows conflicting classes to exist in separate namespaces without issue. However, data structures will need to reference the correct namespace to access the relevant resources. If you want to achieve similar behaviour to {ucd} in {ucn}, configure your resources in the `default` namespace, which means they will be available to all data structures that do not explicitly define a namespace.
 * {ucn} does not support loading resources from the classpath and they should be defined from static locations instead. Resources, including classpath classes, can still be uploaded by clients to the cluster, but you will need to do this using the programmatic API. For more information, see xref:clusters:ucn-dynamic-client.adoc[].
-* Resources in {ucn} can be dynamically added or replaced at runtime. This provides various benefits, but you must ensure that
-resources are not removed from actively running operations, as this could cause errors. For more information, see xref:clusters:ucn-dynamic-config.adoc[].
+* Resources in {ucn} can be dynamically added or replaced at runtime. However, namespaces themselves cannot be removed from a running cluster, even when using dynamic configuration. You must ensure that resources are not removed from actively running operations, as this could cause errors. For more information, see xref:clusters:ucn-dynamic-config.adoc[].

docs/modules/clusters/pages/user-code-namespaces.adoc

@@ -27,7 +27,7 @@ You can configure {ucn} in the following ways:
 
 * Dynamic. This configuration allows you to deploy resources from your client. This method allows you to update your {ucn} at runtime, which means that the next call for a data structure associated with the namespace uses the updated resources. For further information on dynamic configuration, see the xref:ucn-dynamic-config.adoc[] section
 +
-NOTE: When using dynamic configuration, long-running executions are not restarted and continue to use the previous namespace resources until you manually restart them.
+include::partial$ucn-obj-refresh-caution.adoc[]
 +
 You can define resources in your dynamic configuration as follows:
 +
@@ -51,4 +51,4 @@ This is the best way to package JAR files and dependencies for larger deployment
 
 You can define different {ucn} by providing a name and the URLs used to locate the resources. Multiple data structures can reference the same namespace.
 
-You can follow the provided code examples to support your use of the API configuration, as described in the link:https://github.com/hazelcast/hazelcast-code-samples/tree/master/enterprise/user-code-namespaces[Code Samples GitHub repo^].
+You can follow the provided code examples to support your use of the API configuration, as described in the link:https://github.com/hazelcast/hazelcast-code-samples/tree/master/enterprise/user-code-namespaces[Code Samples GitHub repo^].

docs/modules/clusters/partials/ucn-obj-refresh-caution.adoc

@@ -1,3 +1,4 @@
 CAUTION: {ucn} can replace resources dynamically, but this does not affect the lifecycle of existing instances using older class versions.
 This means that the creation of new objects will use new resources (latest bytecode), but existing objects won't be removed and recreated automatically. In this case, manual intervention is needed, such as destroying and recreating the relevant objects, or restarting Hazelcast members.
 This is particularly applicable to long-lived objects tied to the lifecycle of Hazelcast data structures, such as a `MapLoader`: deploying a new version won't replace an existing `MapLoader`, and to refresh such an object, a xref:maintain-cluster:restart-cluster.adoc[cluster restart] is required.
+Dynamic configuration can add new namespaces or replace the resources in an existing namespace, but it cannot remove a namespace from a running cluster.