feat: Fix call-outs in NGINX Gateway Fabric (#976)

As part of the 2.1 release, an invalid call-out style was reintroduced
to the NGINX Gateway Fabric documentation. This commit removes it, and
also restructures an instance of a double call-out pattern, which we
avoid due to visual clutter.

---------

Co-authored-by: Jon Torre <[email protected]>

Author: 2 people

content/ngf/how-to/data-plane-configuration.md

@@ -397,6 +397,16 @@ Each patch has two fields:
 
 Patches are applied in the order they appear in the array. Later patches can override fields set by earlier patches.
 
+**Which patch type should I use?**
+
+- **StrategicMerge** is the default and most user-friendly for Kubernetes-native resources like Deployments and Services. It understands lists and merges fields intelligently (for example, merging containers by name). Use this for most use cases.
+- **Merge** (JSON Merge Patch) is simpler and works well for basic object merges, but does not handle lists or complex merging. Use this if you want to replace entire fields or for non-Kubernetes-native resources.
+- **JSONPatch** is the most powerful and flexible, allowing you to add, remove, or replace specific fields using RFC 6902 operations. Use this for advanced or fine-grained changes, but it is more verbose and error-prone.
+
+If unsure, start with StrategicMerge. Use JSONPatch only if you need to surgically modify fields that cannot be addressed by the other patch types.
+
+Patches are applied after all other NginxProxy configuration is rendered. Invalid patches will result in a validation error and will not be applied.
+
 #### Example: Configure Service with session affinity
 
 ```yaml
@@ -485,18 +495,4 @@ spec:
               publishNotReadyAddresses: true
 ```
 
-In this example, the final Service will have `sessionAffinity: None` and `publishNotReadyAddresses: true` because the second patch overrides the values from the first patch.
-
-{{< note >}}
-**Which patch type should I use?**
-
-- **StrategicMerge** is the default and most user-friendly for Kubernetes-native resources like Deployments and Services. It understands lists and merges fields intelligently (e.g., merging containers by name). Use this for most use cases.
-- **Merge** (JSON Merge Patch) is simpler and works well for basic object merges, but does not handle lists or complex merging. Use this if you want to replace entire fields or for non-Kubernetes-native resources.
-- **JSONPatch** is the most powerful and flexible, allowing you to add, remove, or replace specific fields using RFC 6902 operations. Use this for advanced or fine-grained changes, but it is more verbose and error-prone.
-
-If unsure, start with StrategicMerge. Use JSONPatch only if you need to surgically modify fields that cannot be addressed by the other patch types.
-
-Patches are applied after all other NginxProxy configuration is rendered. Invalid patches will result in a validation error and will not be applied.
-{{< /note >}}
-
----
+In this example, the final Service will have `sessionAffinity: None` and `publishNotReadyAddresses: true` because the second patch overrides the values from the first patch.

content/ngf/install/upgrade-version.md

@@ -13,20 +13,18 @@ It covers the necessary steps for minor versions as well as major versions (such
 
 Many of the nuances in upgrade paths relate to how custom resource definitions (CRDs) are managed.
 
-
 ## Minor NGINX Gateway Fabric upgrades
 
-{{< call-out "important" >}}
-Upgrading from v2.0.x to v2.1 requires the NGINX Gateway Fabric control plane to be uninstalled and then reinstalled to avoid any downtime to user traffic. CRDs do not need to be removed. The NGINX data plane deployment is not affected by this process, and traffic should still flow uninterrupted. The steps are described below.
-{{< /call-out >}}
+Upgrading from v2.0.x to v2.1 requires the NGINX Gateway Fabric control plane to be uninstalled and then reinstalled to avoid any downtime to user traffic. 
+
+CRDs **do not** need to be removed. The NGINX data plane deployment **is not** affected by this process, and traffic should still flow uninterrupted.
 
 {{< call-out "important" >}} NGINX Plus users need a JWT secret before upgrading from version 1.4.0 to 1.5.x.
 
 Follow the steps in [Set up the JWT]({{< ref "/ngf/install/nginx-plus.md#set-up-the-jwt" >}}) to create the Secret.
 
 {{< /call-out >}}
 
-
 ### Upgrade Gateway resources
 
 To upgrade your Gateway API resources, take the following steps: