Remove redundant `**Note:**` from docs

The notation we use to represent a note is:

```
NOTE: **Note:**
This is a note
```

This is rendered by Nanoc and presented in an alert box in the docs
site. The second `**Note:**` can be redundant, so let's remove it.

doc/.vale/gitlab/AlertBoxNoteTip.yml

@@ -5,7 +5,7 @@
 #
 # For a list of all options, see https://errata-ai.gitbook.io/vale/getting-started/styles
 extends: substitution
-message: "NOTE: and TIP: alert boxes must be of the format 'NOTE: **Note:**' or 'TIP: **Tip:**"
+message: "NOTE: and TIP: alert boxes must be of the format 'NOTE:' or 'TIP: **Tip:**"
 link: https://docs.gitlab.com/ee/development/documentation/styleguide.html#alert-boxes
 level: warning
 nonword: true

doc/administration/audit_events.md

@@ -44,7 +44,7 @@ Impersonation is where an administrator uses credentials to perform an action as
 ### Group events **(STARTER)**
-NOTE: **Note:**
+NOTE:
 You need Owner [permissions](../user/permissions.md) to view the group Audit Events page.
 To view a group's audit events, navigate to **Group > Settings > Audit Events**.
@@ -74,7 +74,7 @@ Group events can also be accessed via the [Group Audit Events API](../api/audit_
 ### Project events **(STARTER)**
-NOTE: **Note:**
+NOTE:
 You need Maintainer [permissions](../user/permissions.md) or higher to view the project Audit Events page.
 To view a project's audit events, navigate to **Project > Settings > Audit Events**.

doc/administration/auth/README.md

@@ -36,5 +36,5 @@ providers:
 - [Smartcard](smartcard.md) **(PREMIUM ONLY)**
 - [Twitter](../../integration/twitter.md)
-NOTE: **Note:**
+NOTE:
 UltraAuth has removed their software which supports OmniAuth integration. We have therefore removed all references to UltraAuth integration.

doc/administration/auth/jwt.md

@@ -62,7 +62,7 @@ JWT will provide you with a secret key for you to use.
      }
    ```
-   NOTE: **Note:**
+   NOTE:
    For more information on each configuration option refer to
    the [OmniAuth JWT usage documentation](https://github.com/mbleigh/omniauth-jwt#usage).

doc/administration/auth/ldap/index.md

@@ -91,7 +91,7 @@ There is a Rake task to check LDAP configuration. After configuring LDAP
 using the documentation below, see [LDAP check Rake task](../../raketasks/check.md#ldap-check)
 for information on the LDAP check Rake task.
-NOTE: **Note:**
+NOTE:
 The `encryption` value `simple_tls` corresponds to 'Simple TLS' in the LDAP
 library. `start_tls` corresponds to StartTLS, not to be confused with regular TLS.
 Normally, if you specify `simple_tls` it is on port 636, while `start_tls` (StartTLS)
@@ -553,7 +553,7 @@ administrators. Specify a group CN for `admin_group` and all members of the
 LDAP group will be given administrator privileges. The configuration looks
 like the following.
-NOTE: **Note:**
+NOTE:
 Administrators are not synced unless `group_base` is also
 specified alongside `admin_group`. Also, only specify the CN of the admin
 group, as opposed to the full DN.

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

@@ -378,7 +378,7 @@ GitLab syncs the `admin_group`.
 #### Sync all groups **(STARTER ONLY)**
-NOTE: **Note:**
+NOTE:
 To sync all groups manually when debugging is unnecessary, [use the Rake
 task](../../raketasks/ldap.md#run-a-group-sync) instead.
@@ -429,7 +429,7 @@ and more DNs may be added, or existing entries modified, based on additional
 LDAP group lookups. The very last occurrence of this entry should indicate
 exactly which users GitLab believes should be added to the group.
-NOTE: **Note:**
+NOTE:
 10 is 'Guest', 20 is 'Reporter', 30 is 'Developer', 40 is 'Maintainer'
 and 50 is 'Owner'.

doc/administration/auth/oidc.md

@@ -81,7 +81,7 @@ The OpenID Connect will provide you with a client details and secret for you to
        }
    ```
-   NOTE: **Note:**
+   NOTE:
    For more information on each configuration option refer to the [OmniAuth OpenID Connect usage documentation](https://github.com/m0n9oose/omniauth_openid_connect#usage)
    and the [OpenID Connect Core 1.0 specification](https://openid.net/specs/openid-connect-core-1_0.html).

doc/administration/auth/okta.md

@@ -158,7 +158,7 @@ You might want to try this out on an incognito browser window.
 ## Configuring groups
-NOTE: **Note:**
+NOTE:
 Make sure the groups exist and are assigned to the Okta app.
 You can take a look of the [SAML documentation](../../integration/saml.md#saml-groups) on configuring groups.

doc/administration/auth/smartcard.md

@@ -60,7 +60,7 @@ Certificate:
 Smartcards with X.509 certificates using SAN extensions can be used to authenticate
 with GitLab.
-NOTE: **Note:**
+NOTE:
 This is an experimental feature. Smartcard authentication against local databases may
 change or be removed completely in future releases.
@@ -211,7 +211,7 @@ attribute. As a prerequisite, you must use an LDAP server that:
      client_certificate_required_port: 3443
    ```
-   NOTE: **Note:**
+   NOTE:
    Assign a value to at least one of the following variables:
    `client_certificate_required_host` or `client_certificate_required_port`.

doc/administration/database_load_balancing.md

@@ -173,7 +173,7 @@ queried over UDP. To overcome this issue, you can use TCP for querying by settin
 ### Forking
-NOTE: **Note:**
+NOTE:
 Starting with GitLab 13.0, Puma is the default web server used in GitLab
 all-in-one package based installations as well as GitLab Helm chart deployments.

doc/administration/file_hooks.md

@@ -13,12 +13,12 @@ type: reference
 With custom file hooks, GitLab administrators can introduce custom integrations
 without modifying GitLab's source code.
-NOTE: **Note:**
+NOTE:
 Instead of writing and supporting your own file hook you can make changes
 directly to the GitLab source code and contribute back upstream. This way we can
 ensure functionality is preserved across versions and covered by tests.
-NOTE: **Note:**
+NOTE:
 File hooks must be configured on the filesystem of the GitLab server. Only GitLab
 server administrators will be able to complete these tasks. Explore
 [system hooks](../system_hooks/system_hooks.md) or [webhooks](../user/project/integrations/webhooks.md) as an option if you do not have filesystem access.

doc/administration/geo/disaster_recovery/background_verification.md

@@ -7,7 +7,7 @@ type: howto
 # Automatic background verification **(PREMIUM ONLY)**
-NOTE: **Note:**
+NOTE:
 Automatic background verification of repositories and wikis was added in
 GitLab EE 10.6 but is enabled by default only on GitLab EE 11.1. You can
 disable or enable this feature manually by following

doc/administration/geo/disaster_recovery/bring_primary_back.md

@@ -32,14 +32,14 @@ To bring the former **primary** node up to date:
    sudo gitlab-ctl start
    ```
-   NOTE: **Note:**
+   NOTE:
    If you [disabled the **primary** node permanently](index.md#step-2-permanently-disable-the-primary-node),
    you need to undo those steps now. For Debian/Ubuntu you just need to run
    `sudo systemctl enable gitlab-runsvdir`. For CentOS 6, you need to install
    the GitLab instance from scratch and set it up as a **secondary** node by
    following [Setup instructions](../setup/index.md). In this case, you don't need to follow the next step.
-   NOTE: **Note:**
+   NOTE:
    If you [changed the DNS records](index.md#step-4-optional-updating-the-primary-domain-dns-record)
    for this node during disaster recovery procedure you may need to [block
    all the writes to this node](planned_failover.md#prevent-updates-to-the-primary-node)

doc/administration/geo/disaster_recovery/index.md

@@ -58,7 +58,7 @@ must disable the **primary** node.
    sudo systemctl disable gitlab-runsvdir
    ```
-   NOTE: **Note:**
+   NOTE:
    (**CentOS only**) In CentOS 6 or older, there is no easy way to prevent GitLab from being
    started if the machine reboots isn't available (see [Omnibus GitLab issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3058)).
    It may be safest to uninstall the GitLab package completely:
@@ -67,7 +67,7 @@ must disable the **primary** node.
    yum remove gitlab-ee
    ```
-   NOTE: **Note:**
+   NOTE:
    (**Ubuntu 14.04 LTS**) If you are using an older version of Ubuntu
    or any other distribution based on the Upstart init system, you can prevent GitLab
    from starting if the machine reboots by doing the following:
@@ -301,7 +301,7 @@ secondary domain, like changing Git remotes and API URLs.
    external_url 'https://<new_external_url>'
    ```
-   NOTE: **Note:**
+   NOTE:
    Changing `external_url` won't prevent access via the old secondary URL, as
    long as the secondary DNS records are still intact.

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

@@ -58,7 +58,7 @@ What is not covered:
 ### Preparation
-NOTE: **Note:**
+NOTE:
 Before following any of those steps, make sure you have `root` access to the
 **secondary** to promote it, since there isn't provided an automated way to
 promote a Geo replica and perform a failover.
@@ -188,12 +188,12 @@ follow these steps to avoid unnecessary data loss:
      sudo systemctl disable gitlab-runsvdir
      ```
-     NOTE: **Note:**
+     NOTE:
      (**CentOS only**) In CentOS 6 or older, there is no easy way to prevent GitLab from being
      started if the machine reboots isn't available (see [Omnibus GitLab issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3058)).
      It may be safest to uninstall the GitLab package completely with `sudo yum remove gitlab-ee`.
-     NOTE: **Note:**
+     NOTE:
      (**Ubuntu 14.04 LTS**) If you are using an older version of Ubuntu
      or any other distribution based on the Upstart init system, you can prevent GitLab
      from starting if the machine reboots as `root` with
@@ -213,7 +213,7 @@ follow these steps to avoid unnecessary data loss:
 ### Promoting the **secondary** node
-NOTE: **Note:**
+NOTE:
 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**.

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

@@ -46,7 +46,7 @@ What is not covered:
 ### Preparation
-NOTE: **Note:**
+NOTE:
 Before following any of those steps, make sure you have `root` access to the
 **secondary** to promote it, since there isn't provided an automated way to
 promote a Geo replica and perform a failover.
@@ -176,12 +176,12 @@ follow these steps to avoid unnecessary data loss:
      sudo systemctl disable gitlab-runsvdir
      ```
-     NOTE: **Note:**
+     NOTE:
      (**CentOS only**) In CentOS 6 or older, there is no easy way to prevent GitLab from being
      started if the machine reboots isn't available (see [Omnibus GitLab issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3058)).
      It may be safest to uninstall the GitLab package completely with `sudo yum remove gitlab-ee`.
-     NOTE: **Note:**
+     NOTE:
      (**Ubuntu 14.04 LTS**) If you are using an older version of Ubuntu
      or any other distribution based on the Upstart init system, you can prevent GitLab
      from starting if the machine reboots as `root` with

doc/administration/geo/index.md

@@ -143,11 +143,11 @@ The following table lists basic ports that must be open between the **primary**
 See the full list of ports used by GitLab in [Package defaults](https://docs.gitlab.com/omnibus/package-information/defaults.html)
-NOTE: **Note:**
+NOTE:
 [Web terminal](../../ci/environments/index.md#web-terminals) support requires your load balancer to correctly handle WebSocket connections.
 When using HTTP or HTTPS proxying, your load balancer must be configured to pass through the `Connection` and `Upgrade` hop-by-hop headers. See the [web terminal](../integration/terminal.md) integration guide for more details.
-NOTE: **Note:**
+NOTE:
 When using HTTPS protocol for port 443, you will need to add an SSL certificate to the load balancers.
 If you wish to terminate SSL at the GitLab application server instead, use TCP protocol.
@@ -155,7 +155,7 @@ If you wish to terminate SSL at the GitLab application server instead, use TCP p
 We recommend that if you use LDAP on your **primary** node, you also set up secondary LDAP servers on each **secondary** node. Otherwise, users will not be able to perform Git operations over HTTP(s) on the **secondary** node using HTTP Basic Authentication. However, Git via SSH and personal access tokens will still work.
-NOTE: **Note:**
+NOTE:
 It is possible for all **secondary** nodes to share an LDAP server, but additional latency can be an issue. Also, consider what LDAP server will be available in a [disaster recovery](disaster_recovery/index.md) scenario if a **secondary** node is promoted to be a **primary** node.
 Check for instructions on how to set up replication in your LDAP service. Instructions will be different depending on the software or service used. For example, OpenLDAP provides [these instructions](https://www.openldap.org/doc/admin24/replication.html).

doc/administration/geo/replication/configuration.md

@@ -9,7 +9,7 @@ type: howto
 ## Configuring a new **secondary** node
-NOTE: **Note:**
+NOTE:
 This is the final step in setting up a **secondary** Geo node. Stages of the
 setup process must be completed in the documented order.
 Before attempting the steps in this stage, [complete all prior stages](../setup/index.md#using-omnibus-gitlab).
@@ -23,7 +23,7 @@ The basic steps of configuring a **secondary** node are to:
 You are encouraged to first read through all the steps before executing them
 in your testing/production environment.
-NOTE: **Note:**
+NOTE:
 **Do not** set up any custom authentication for the **secondary** nodes. This will be handled by the **primary** node.
 Any change that requires access to the **Admin Area** needs to be done in the
 **primary** node because the **secondary** node is a read-only replica.
@@ -157,7 +157,7 @@ keys must be manually replicated to the **secondary** node.
    for file in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf $file; done
    ```
-   NOTE: **Note:**
+   NOTE:
    The output for private keys and public keys command should generate the same fingerprint.
 1. Restart `sshd` on your **secondary** node:

doc/administration/geo/replication/docker_registry.md

@@ -64,17 +64,17 @@ We need to make Docker Registry send notification events to the
    ]
    ```
-   NOTE: **Note:**
+   NOTE:
    Replace `<replace_with_a_secret_token>` with a case sensitive alphanumeric string
    that starts with a letter. You can generate one with `< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32 | sed "s/^[0-9]*//"; echo`
-   NOTE: **Note:**
+   NOTE:
    If you use an external Registry (not the one integrated with GitLab), you must add
    these settings to its configuration yourself. In this case, you will also have to specify
    notification secret in `registry.notification_secret` section of
    `/etc/gitlab/gitlab.rb` file.
-   NOTE: **Note:**
+   NOTE:
    If you use GitLab HA, you will also have to specify
    the notification secret in `registry.notification_secret` section of
    `/etc/gitlab/gitlab.rb` file for every web node.

doc/administration/geo/replication/location_aware_git_url.md

@@ -18,7 +18,7 @@ Though these instructions use [AWS Route53](https://aws.amazon.com/route53/),
 other services such as [Cloudflare](https://www.cloudflare.com/) could be used
 as well.
-NOTE: **Note:**
+NOTE:
 You can also use a load balancer to distribute web UI or API traffic to
 [multiple Geo **secondary** nodes](../../../user/admin_area/geo_nodes.md#multiple-secondary-nodes-behind-a-load-balancer).
 Importantly, the **primary** node cannot yet be included. See the feature request