ci: use markdownlint to enforce mkdocs compatibility

mkdocs uses a markdown renderer that is hardcoded to 4 spaces per tab
for detecting indentation levels, including ordered- and
unordered-lists. Since we cannot easily change the renderer, begin using
a markdown linter in CI that will fail if official docs do not adhere to
the spacing rules.

As a starting point, the markdownlint config does not begin with the
default set of checks, which might overwhelm attempts to fix them.
Instead, focus on list-tab-spacing rules and a few other highly useful
checks.

markdownlint also has some gaps in its abilities that allow common Rook
doc issues to pass acceptance. However, it allows creating custom
linting plugins. Create 2 such linting plugins to check 2 things:

- all doc lines (except code blocks) must be aligned to a 4-space
  boundary, without exception. This ensures that markdown will render
  correctly with mkdocs. This unfortunately makes it possible to create
  lists that are internally aligned strangely.
- admonitions must all follow the same format of
  ```
  !!! header
      body
  ```

For the strange lists, this is allowed and renders correctly, but it
looks strange:

```md
- first bullet
- second bullet
    still second bullet
- third bullet

    has a paragraph
    of text inside

- last bullet

Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>
(cherry picked from commit c9d99e01a0)

Documentation/Storage-Configuration/Object-Storage-RGW/ceph-object-multisite.md

@@ -26,9 +26,9 @@ This guide assumes a Rook cluster as explained in the [Quickstart](../../Getting
 If an admin wants to set up multisite on a Rook Ceph cluster, the following resources must be created:
 
 1. A [realm](../../CRDs/Object-Storage/ceph-object-realm-crd.md#settings)
-1. A [zonegroup](../../CRDs/Object-Storage/ceph-object-zonegroup-crd.md#settings)
-1. A [zone](../../CRDs/Object-Storage/ceph-object-zone-crd.md#settings)
-1. A ceph object store with the `zone` section
+2. A [zonegroup](../../CRDs/Object-Storage/ceph-object-zonegroup-crd.md#settings)
+3. A [zone](../../CRDs/Object-Storage/ceph-object-zone-crd.md#settings)
+4. A ceph object store with the `zone` section
 
 object-multisite.yaml in the [examples](https://github.com/rook/rook/blob/master/deploy/examples/) directory can be used to create the multisite CRDs.
 
@@ -45,6 +45,7 @@ The zone will create the pools for the object-store(s) that are in the zone to u
 When one of the multisite CRs (realm, zone group, zone) is deleted the underlying ceph realm/zone group/zone is not deleted, neither are the pools created by the zone. See the "Multisite Cleanup" section for more information.
 
 For more information on the multisite CRDs, see the related CRDs:
+
 - [CephObjectRealm](../../CRDs/Object-Storage/ceph-object-realm-crd.md)
 - [CephObjectZoneGroup](../../CRDs/Object-Storage/ceph-object-zonegroup-crd.md)
 - [CephObjectZone](../../CRDs/Object-Storage/ceph-object-zone-crd.md)
@@ -56,7 +57,7 @@ If an admin wants to sync data from another cluster, the admin needs to pull a r
 To begin doing this, the admin needs 2 pieces of information:
 
 1. An endpoint from the realm being pulled from
-1. The access key and the system key of the system user from the realm being pulled from.
+2. The access key and the system key of the system user from the realm being pulled from.
 
 ### Getting the Pull Endpoint
 
@@ -176,9 +177,9 @@ kubectl create -f realm-a-keys.yaml
 Once the admin knows the endpoint and the secret for the keys has been created, the admin should create:
 
 1. A [CephObjectRealm](../../CRDs/Object-Storage/ceph-object-realm-crd.md#settings) matching to the realm on the other Ceph cluster, with an endpoint as described above.
-1. A [CephObjectZoneGroup](../../CRDs/Object-Storage/ceph-object-zonegroup-crd.md#settings) matching the master zone group name or the master CephObjectZoneGroup from the cluster the realm was pulled from.
-1. A [CephObjectZone](../../CRDs/Object-Storage/ceph-object-zone-crd.md#settings) referring to the CephObjectZoneGroup created above.
-1. A CephObjectStore referring to the new CephObjectZone resource.
+2. A [CephObjectZoneGroup](../../CRDs/Object-Storage/ceph-object-zonegroup-crd.md#settings) matching the master zone group name or the master CephObjectZoneGroup from the cluster the realm was pulled from.
+3. A [CephObjectZone](../../CRDs/Object-Storage/ceph-object-zone-crd.md#settings) referring to the CephObjectZoneGroup created above.
+4. A CephObjectStore referring to the new CephObjectZone resource.
 
 object-multisite-pull-realm.yaml (with changes) in the [examples](https://github.com/rook/rook/blob/master/deploy/examples/) directory can be used to create the multisite CRDs.
 
@@ -346,6 +347,7 @@ Removing object store(s) from the master zone of the master zone group should be
 ## Configure an Existing Object Store for Multisite
 
 When an object store is configured by Rook, it internally creates a zone, zone group, and realm with the same name as the object store. To enable multisite, you will need to create the corresponding zone, zone group, and realm CRs with the same name as the object store. For example, to create multisite CRs for an object store named `my-store`:
+
 ```yaml
 apiVersion: ceph.rook.io/v1
 kind: CephObjectRealm
@@ -398,11 +400,13 @@ spec:
 
 #### Using custom names
 If names different from the object store need to be set for the realm, zone, or zone group, first rename them in the backend via toolbox pod, then following the procedure above.
+
 ```console
 radosgw-admin realm rename --rgw-realm=my-store --realm-new-name=<new-realm-name>
 radosgw-admin zonegroup rename --rgw-zonegroup=my-store --zonegroup-new-name=<new-zonegroup-name> --rgw-realm=<new-realm-name>
 radosgw-admin zone rename --rgw-zone=my-store --zone-new-name=<new-zone-name>  --rgw-zonegroup=<new-zonegroup-name> --rgw-realm=<new-realm-name>
 radosgw-admin period update --commit
 ```
+
 !!! important
     Renaming in the toolbox must be performed **before** creating the multisite CRs