Change CAUTION to WARNING in documentation alerts

In https://gitlab.com/groups/gitlab-org/-/epics/5020, we decided to
use only two alerts (note, warning), and eliminate any bold text
coming after the icon.

This changes CAUTION to WARNING and eliminates any
**Warning:**/**Caution:** text that comes after them.

doc/administration/auth/ldap/index.md

@@ -615,7 +615,7 @@ By default, GitLab runs a group sync process every hour, on the hour.
 The values shown are in cron format. If needed, you can use a
 [Crontab Generator](http://www.crontabgenerator.com).
-CAUTION: **Important:**
+WARNING:
 Do not start the sync process too frequently as this
 could lead to multiple syncs running concurrently. This is primarily a concern
 for installations with a large number of LDAP users. Please review the

doc/administration/auth/ldap/ldap-troubleshooting.md

@@ -673,7 +673,7 @@ adfind -h ad.example.org:636 -ssl -u "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" -u
 ### Rails console
-CAUTION: **Caution:**
+WARNING:
 It is very easy to create, read, modify, and destroy data with the rails
 console. Be sure to run commands exactly as listed.

doc/administration/auth/smartcard.md

@@ -30,7 +30,7 @@ GitLab supports two authentication methods:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/726) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.6 as an experimental feature.
-CAUTION: **Caution:**
+WARNING:
 Smartcard authentication against local databases may change or be removed completely in future
 releases.

doc/administration/external_pipeline_validation.md

@@ -9,7 +9,7 @@ type: reference, howto
 You can use an external service for validating a pipeline before it's created.
-CAUTION: **Warning:**
+WARNING:
 This is an experimental feature and subject to change without notice.
 ## Usage

doc/administration/feature_flags.md

@@ -36,7 +36,7 @@ error, it's very important that you [**provide feedback**](https://gitlab.com/gi
 as possible so we can improve or fix it while behind a flag. When you upgrade
 GitLab to an earlier version, the feature flag status may change.
-CAUTION: **Caution:**
+WARNING:
 Features deployed behind feature flags may not be ready for
 production use. However, disabling features behind flags that were deployed
 enabled by default may also present a risk. If they're enabled, we recommend

doc/administration/geo/disaster_recovery/bring_primary_back.md

@@ -13,7 +13,7 @@ restore your original configuration. This process consists of two steps:
 1. Making the old **primary** node a **secondary** node.
 1. Promoting a **secondary** node to a **primary** node.
-CAUTION: **Caution:**
+WARNING:
 If you have any doubts about the consistency of the data on this node, we recommend setting it up from scratch.
 ## Configure the former **primary** node to be a **secondary** node

doc/administration/geo/disaster_recovery/index.md

@@ -13,7 +13,7 @@ failover with minimal effort, in a disaster situation.
 See [Geo limitations](../index.md#limitations) for more information.
-CAUTION: **Warning:**
+WARNING:
 Disaster recovery for multi-secondary configurations is in **Alpha**.
 For the latest updates, check the [Disaster Recovery epic for complete maturity](https://gitlab.com/groups/gitlab-org/-/epics/590).
 Multi-secondary configurations require the complete re-synchronization and re-configuration of all non-promoted secondaries and
@@ -36,7 +36,7 @@ order to avoid unnecessary data loss.
 ### Step 2. Permanently disable the **primary** node
-CAUTION: **Warning:**
+WARNING:
 If the **primary** node goes offline, there may be data saved on the **primary** node
 that has not been replicated to the **secondary** node. This data should be treated
 as lost if you proceed.
@@ -140,7 +140,7 @@ Note the following when promoting a secondary:
    secondary. If the node is paused, be sure to resume before promoting. This
    issue has been fixed in GitLab 13.4 and later.
-   CAUTION: **Caution:**
+   WARNING:
    If the secondary node [has been paused](../../geo/index.md#pausing-and-resuming-replication), this performs
    a point-in-time recovery to the last known state.
    Data that was created on the primary while the secondary was paused will be lost.
@@ -180,7 +180,7 @@ secondary is paused fails. Do not pause replication before promoting a
 secondary. If the node is paused, be sure to resume before promoting. This
 issue has been fixed in GitLab 13.4 and later.
-CAUTION: **Caution:**
+WARNING:
    If the secondary node [has been paused](../../geo/index.md#pausing-and-resuming-replication), this performs
 a point-in-time recovery to the last known state.
 Data that was created on the primary while the secondary was paused will be lost.

doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md

@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: howto
 ---
-CAUTION: **Caution:**
+WARNING:
 This runbook is in **alpha**. For complete, production-ready documentation, see the
 [disaster recovery documentation](../index.md).
@@ -134,7 +134,7 @@ follow these steps to avoid unnecessary data loss:
 1. Finish replicating and verifying all data:
-   CAUTION: **Caution:**
+   WARNING:
    Not all data is automatically replicated. Read more about
    [what is excluded](../planned_failover.md#not-all-data-is-automatically-replicated).
@@ -163,7 +163,7 @@ follow these steps to avoid unnecessary data loss:
 1. In this final step, you need to permanently disable the **primary** node.
-   CAUTION: **Caution:**
+   WARNING:
    When the **primary** node goes offline, there may be data saved on the **primary** node
    that has not been replicated to the **secondary** node. This data should be treated
    as lost if you proceed.
@@ -218,7 +218,7 @@ A new **secondary** should not be added at this time. If you want to add a new
 **secondary**, do this after you have completed the entire process of promoting
 the **secondary** to the **primary**.
-CAUTION: **Caution:**
+WARNING:
 If you encounter an `ActiveRecord::RecordInvalid: Validation failed: Name has already been taken` error during this process, read
 [the troubleshooting advice](../../replication/troubleshooting.md#fixing-errors-during-a-failover-or-when-promoting-a-secondary-to-a-primary-node).
@@ -233,7 +233,7 @@ secondary is paused fails. Do not pause replication before promoting a
 secondary. If the node is paused, be sure to resume before promoting. This
 issue has been fixed in GitLab 13.4 and later.
-CAUTION: **Caution:**
+WARNING:
    If the secondary node [has been paused](../../../geo/index.md#pausing-and-resuming-replication), this performs
 a point-in-time recovery to the last known state.
 Data that was created on the primary while the secondary was paused will be lost.

doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md

@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: howto
 ---
-CAUTION: **Caution:**
+WARNING:
 This runbook is in **alpha**. For complete, production-ready documentation, see the
 [disaster recovery documentation](../index.md).
@@ -122,7 +122,7 @@ follow these steps to avoid unnecessary data loss:
 1. Finish replicating and verifying all data:
-   CAUTION: **Caution:**
+   WARNING:
    Not all data is automatically replicated. Read more about
    [what is excluded](../planned_failover.md#not-all-data-is-automatically-replicated).
@@ -151,7 +151,7 @@ follow these steps to avoid unnecessary data loss:
 1. In this final step, you need to permanently disable the **primary** node.
-   CAUTION: **Caution:**
+   WARNING:
    When the **primary** node goes offline, there may be data saved on the **primary** node
    that has not been replicated to the **secondary** node. This data should be treated
    as lost if you proceed.

doc/administration/geo/index.md

@@ -17,7 +17,7 @@ Geo is the solution for widely distributed development teams and for providing a
 ## Overview
-CAUTION: **Caution:**
+WARNING:
 Geo undergoes significant changes from release to release. Upgrades **are** supported and [documented](#updating-geo), but you should ensure that you're using the right version of the documentation for your installation.
 Fetching large repositories can take a long time for teams located far from a single GitLab instance.
@@ -207,7 +207,7 @@ secondary is paused fails. Do not pause replication before promoting a
 secondary. If the node is paused, be sure to resume before promoting. This
 issue has been fixed in GitLab 13.4 and later.
-CAUTION: **Caution:**
+WARNING:
 Pausing and resuming of replication is currently only supported for Geo installations using an
 Omnibus GitLab-managed database. External databases are currently not supported.
@@ -267,7 +267,7 @@ To find out how to disable Geo, see [Disabling Geo](replication/disable_geo.md).
 ## Limitations
-CAUTION: **Caution:**
+WARNING:
 This list of limitations only reflects the latest version of GitLab. If you are using an older version, extra limitations may be in place.
 - Pushing directly to a **secondary** node redirects (for HTTP) or proxies (for SSH) the request to the **primary** node instead of [handling it directly](https://gitlab.com/gitlab-org/gitlab/-/issues/1381), except when using Git over HTTP with credentials embedded within the URI. For example, `https://user:password@secondary.tld`.

doc/administration/geo/replication/object_storage.md

@@ -25,7 +25,7 @@ To have:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10586) in GitLab 12.4.
-CAUTION: **Caution:**
+WARNING:
 This is a [**beta** feature](https://about.gitlab.com/handbook/product/#beta) and is not ready yet for production use at any scale. The main limitations are a lack of testing at scale and no verification of any replicated data.
 **Secondary** nodes can replicate files stored on the **primary** node regardless of

doc/administration/geo/replication/troubleshooting.md

@@ -467,7 +467,7 @@ to start again from scratch, there are a few steps that can help you:
 1. _(Optional)_ Rename other data folders and create new ones
-   CAUTION: **Caution:**
+   WARNING:
    You may still have files on the **secondary** node that have been removed from **primary** node but
    removal have not been reflected. If you skip this step, they will never be removed
    from this Geo node.

doc/administration/geo/replication/updating_the_geo_nodes.md

@@ -7,7 +7,7 @@ type: howto
 # Updating the Geo nodes **(PREMIUM ONLY)**
-CAUTION: **Warning:**
+WARNING:
 Read these sections carefully before updating your Geo nodes. Not following
 version-specific update steps may result in unexpected downtime. If you have
 any specific questions, [contact Support](https://about.gitlab.com/support/#contact-support).

doc/administration/geo/replication/version_specific_updates.md

@@ -54,7 +54,7 @@ the recommended procedure, see the
 ## Updating to GitLab 12.9
-CAUTION: **Warning:**
+WARNING:
 GitLab 12.9.0 through GitLab 12.9.3 are affected by [a bug that stops
 repository verification](https://gitlab.com/gitlab-org/gitlab/-/issues/213523).
 The issue is fixed in GitLab 12.9.4. Upgrade to GitLab 12.9.4 or later.
@@ -203,14 +203,14 @@ For the recommended procedure, see the
 ## Updating to GitLab 12.0
-CAUTION: **Warning:**
+WARNING:
 This version is affected by a [bug that results in new LFS objects not being
 replicated to Geo secondary nodes](https://gitlab.com/gitlab-org/gitlab/-/issues/32696).
 The issue is fixed in GitLab 12.1; be sure to upgrade to GitLab 12.1 or later.
 ## Updating to GitLab 11.11
-CAUTION: **Warning:**
+WARNING:
 This version is affected by a [bug that results in new LFS objects not being
 replicated to Geo secondary nodes](https://gitlab.com/gitlab-org/gitlab/-/issues/32696).
 The issue is fixed in GitLab 12.1; be sure to upgrade to GitLab 12.1 or later.
@@ -376,7 +376,7 @@ the now-unused SSH keys from your secondaries, as they may cause problems if the
 ### Hashed Storage
-CAUTION: **Warning:**
+WARNING:
 Hashed storage is in **Alpha**. It is considered experimental and not
 production-ready. See [Hashed Storage](../../repository_storage_types.md) for more detail.
@@ -387,7 +387,7 @@ migrated we recommend leaving Hashed Storage enabled.
 ## Updating to GitLab 10.1
-CAUTION: **Warning:**
+WARNING:
 Hashed storage is in **Alpha**. It is considered experimental and not
 production-ready. See [Hashed Storage](../../repository_storage_types.md) for more detail.

doc/administration/geo/setup/database.md

@@ -44,7 +44,7 @@ The following guide assumes that:
   you have a new **secondary** server set up with the same versions of the OS,
   PostgreSQL, and GitLab on all nodes.
-CAUTION: **Warning:**
+WARNING:
 Geo works with streaming replication. Logical replication is not supported at this time.
 There is an [issue where support is being discussed](https://gitlab.com/gitlab-org/gitlab/-/issues/7420).
@@ -404,7 +404,7 @@ needed files for streaming replication.
 The directories used are the defaults that are set up in Omnibus. If you have
 changed any defaults, configure it as you see fit replacing the directories and paths.
-CAUTION: **Warning:**
+WARNING:
 Make sure to run this on the **secondary** server as it removes all PostgreSQL's
 data before running `pg_basebackup`.
@@ -421,7 +421,7 @@ data before running `pg_basebackup`.
 1. Execute the command below to start a backup/restore and begin the replication
-   CAUTION: **Warning:**
+   WARNING:
    Each Geo **secondary** node must have its own unique replication slot name.
    Using the same slot name between two secondaries will break PostgreSQL replication.

doc/administration/geo/setup/index.md

@@ -12,7 +12,7 @@ These instructions assume you have a working instance of GitLab. They guide you
 1. Making your existing instance the **primary** node.
 1. Adding **secondary** nodes.
-CAUTION: **Caution:**
+WARNING:
 The steps below should be followed in the order they appear. **Make sure the GitLab version is the same on all nodes.**
 ## Using Omnibus GitLab

doc/administration/git_annex.md

@@ -8,7 +8,7 @@ disqus_identifier: 'https://docs.gitlab.com/ee/workflow/git_annex.html'
 # Git annex
-CAUTION: **Warning:**
+WARNING:
 [Git Annex support was removed](https://gitlab.com/gitlab-org/gitlab/-/issues/1648)
 in GitLab 9.0. Read through the [migration guide from git-annex to Git LFS](../topics/git/lfs/migrate_from_git_annex_to_git_lfs.md).

doc/administration/gitaly/index.md

@@ -22,7 +22,7 @@ In the Gitaly documentation:
 GitLab end users do not have direct access to Gitaly. Gitaly only manages Git
 repository access for GitLab. Other types of GitLab data aren't accessed using Gitaly.
-CAUTION: **Caution:**
+WARNING:
 From GitLab 13.0, Gitaly support for NFS is deprecated. As of GitLab 14.0, NFS-related issues
 with Gitaly will no longer be addressed. Upgrade to [Gitaly Cluster](praefect.md) as soon as
 possible. Watch for [tools to enable bulk move](https://gitlab.com/groups/gitlab-org/-/epics/4916)
@@ -915,7 +915,7 @@ your Gitaly servers as follows:
 gitaly['auth_transitioning'] = false
 ```
-CAUTION: **Caution:**
+WARNING:
 Without completing this step, you have **no Gitaly authentication**.
 ### Verify authentication is enforced

doc/administration/gitaly/praefect.md

@@ -398,7 +398,7 @@ application server, or a Gitaly node.
    so we use `default` here as well. This cluster has three Gitaly nodes `gitaly-1`,
    `gitaly-2`, and `gitaly-3`, which are intended to be replicas of each other.
-   CAUTION: **Caution:**
+   WARNING:
    If you have data on an already existing storage called
    `default`, you should configure the virtual storage with another name and
    [migrate the data to the Gitaly Cluster storage](#migrate-existing-repositories-to-gitaly-cluster)
@@ -817,7 +817,7 @@ Particular attention should be shown to:
 1. Disable the default Gitaly service running on the GitLab host. It isn't needed
    because GitLab connects to the configured cluster.
-   CAUTION: **Caution:**
+   WARNING:
    If you have existing data stored on the default Gitaly storage,
    you should [migrate the data your Gitaly Cluster storage](#migrate-existing-repositories-to-gitaly-cluster)
    first.
@@ -1214,7 +1214,7 @@ Praefect provides the following subcommands to re-enable writes:
   sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml accept-dataloss -virtual-storage <virtual-storage> -repository <relative-path> -authoritative-storage <storage-name>
   ```
-CAUTION: **Caution:**
+WARNING:
 `accept-dataloss` causes permanent data loss by overwriting other versions of the repository. Data
 [recovery efforts](#data-recovery) must be performed before using it.

doc/administration/gitaly/reference.md

@@ -66,7 +66,7 @@ token = "the secret token"
 transitioning = true
 ```
-CAUTION: **Warning:**
+WARNING:
 Remember to disable `transitioning` when you are done
 changing your token settings.