(DOCSP-26419): Replace Agg-Collation doc directives (#2174)

* replace doc directives

* fix build and a few outliers

* small fix from copy review

Author: davidhou17

source/administration/production-checklist-operations.txt

@@ -107,8 +107,8 @@ Sharding
 
 .. cssclass:: checklist
 
-   - Place your :doc:`config servers
-     </core/sharded-cluster-config-servers>` on dedicated hardware for
+   - Place your :ref:`config servers
+     <sharding-config-server>` on dedicated hardware for
      optimal performance in large clusters. Ensure that the hardware has
      enough RAM to hold the data files entirely in memory and that it
      has dedicated storage.

source/aggregation.txt

@@ -1,3 +1,5 @@
+.. _aggregation:
+
 ======================
 Aggregation Operations
 ======================

source/core/authorization.txt

@@ -26,8 +26,8 @@ authorization using the :option:`--auth <mongod --auth>` or the
 authentication </core/security-internal-authentication>` also enables
 client authorization.
 
-Once access control is enabled, users must :doc:`authenticate
-</core/authentication>` themselves.
+Once access control is enabled, users must :ref:`authenticate
+<authentication>` themselves.
 
 .. _roles:
 

source/core/data-model-operations.txt

@@ -19,7 +19,7 @@ increase the throughput of insert and update operations, or distribute
 activity to a sharded cluster more effectively.
 
 When developing a data model, analyze all of your application's
-:doc:`read and write operations </crud>` in conjunction with the
+:ref:`read and write operations <crud>` in conjunction with the
 following considerations.
 
 .. _data-model-atomicity:

source/core/document.txt

@@ -15,7 +15,7 @@ Documents
 MongoDB stores data records as BSON documents. BSON is a binary
 representation of :term:`JSON` documents, though it contains more data
 types than JSON. For the BSON spec, see `bsonspec.org
-<http://bsonspec.org/>`_. See also :doc:`/reference/bson-types`.
+<http://bsonspec.org/>`_. See also :ref:`bson-types`.
 
 .. include:: /images/crud-annotated-document.rst
 
@@ -37,8 +37,8 @@ following structure:
       fieldN: valueN
    }
 
-The value of a field can be any of the BSON :doc:`data types
-</reference/bson-types>`, including other documents, arrays, and arrays
+The value of a field can be any of the BSON :ref:`data types
+<bson-types>`, including other documents, arrays, and arrays
 of documents. For example, the following document contains values of varying types:
 
 .. code-block:: javascript
@@ -252,8 +252,8 @@ The ``_id`` field has the following behavior and constraints:
 _ If the ``_id`` contains subfields, the subfield names cannot begin
   with a (``$``) symbol.
 
-- The ``_id`` field may contain values of any :doc:`BSON data type
-  </reference/bson-types>`, other than an array, regex, or undefined.
+- The ``_id`` field may contain values of any :ref:`BSON data type
+  <bson-types>`, other than an array, regex, or undefined.
 
   .. warning:: To ensure functioning replication, do not store values
      that are of the BSON regular expression type in the ``_id``

source/core/hashed-sharding.txt

@@ -80,7 +80,7 @@ inserts similar to the following:
 .. include:: /images/sharded-cluster-monotonic-distribution.rst
 
 Since the value of ``X`` is always increasing, the chunk with an upper bound
-of :doc:`maxKey</reference/bson-types>` receives the majority incoming writes. This
+of :bsontype:`MaxKey` receives the majority incoming writes. This
 restricts insert operations to the single shard containing this chunk, which
 reduces or removes the advantage of distributed writes in a sharded cluster.
 
@@ -178,7 +178,7 @@ Sharding Empty Collection on Compound Hashed Shard Key with Hashed Field Prefix
 
     - The sharding operation creates empty chunks to cover the entire
       range of the shard key values and performs an initial chunk
-      distribution. The value of all non-hashed fields is ``MinKey`` at
+      distribution. The value of all non-hashed fields is :bsontype:`MinKey` at
       each split point. By default, the operation creates 2 chunks per
       shard and migrates across the cluster. You can use
       ``numInitialChunks`` option to specify a different number of

source/core/index-creation.txt

@@ -324,8 +324,8 @@ can occur, such as:
   fails to build the index for an associated shard or incorrectly
   builds an index with different specification.
 
-Starting in MongoDB 4.4 (and in MongoDB 4.2.6), the :doc:`config server
-</core/sharded-cluster-config-servers>` primary periodically checks for
+Starting in MongoDB 4.4 (and in MongoDB 4.2.6), the :ref:`config server
+<sharding-config-server>` primary periodically checks for
 index inconsistencies across the shards for sharded collections. To
 configure these periodic checks, see
 :parameter:`enableShardedIndexConsistencyCheck` and

source/core/security-transport-encryption.txt

@@ -253,8 +253,8 @@ Identity Verification
 ---------------------
 
 In addition to encrypting connections, TLS/SSL allows for authentication
-using certificates, both for :doc:`client authentication
-</core/authentication>` and for :doc:`internal authentication
+using certificates, both for :ref:`client authentication
+<authentication>` and for :doc:`internal authentication
 </core/security-internal-authentication>` of members of replica sets and
 sharded clusters.
 

source/core/sharded-cluster-config-servers.txt

@@ -30,7 +30,7 @@ updates the cache when there are metadata changes for the cluster, such
 as :ref:`adding a shard <sharding-procedure-add-shard>`. Shards also read 
 chunk metadata from the config servers.
 
-The config servers also store :doc:`authentication` configuration
+The config servers also store :ref:`authentication` configuration
 information such as :doc:`Role-Based Access
 Control</core/authorization>` or :doc:`internal
 authentication</core/security-internal-authentication>` settings for
@@ -79,8 +79,8 @@ collections <metadata-system-collections>` for internal use.
 The :doc:`config database </reference/config-database>` contains the
 collections that contain the sharded cluster metadata. MongoDB writes
 data to the :doc:`config database </reference/config-database>` when
-the metadata changes, such as after a :doc:`chunk migration
-</core/sharding-balancer-administration>` or a :doc:`chunk split
+the metadata changes, such as after a :ref:`chunk migration
+<sharding-balancing>` or a :doc:`chunk split
 </core/sharding-data-partitioning>`.
 
 Users should avoid writing directly to the config database in the

source/core/sharding-choose-a-shard-key.txt

@@ -124,10 +124,10 @@ A shard key on a value that increases or decreases monotonically is more
 likely to distribute inserts to a single chunk within the cluster.
 
 This occurs because every cluster has a chunk that captures a range with
-an upper bound of :doc:`maxKey</reference/bson-types>`. ``maxKey``
+an upper bound of :bsontype:`MaxKey`. ``maxKey``
 always compares as higher than all other values. Similarly, there is a
 chunk that captures a range with a lower bound of
-:doc:`minKey</reference/bson-types>`. ``minKey`` always compares as
+:bsontype:`MinKey`. ``minKey`` always compares as
 lower than all other values.
 
 If the shard key value is always increasing, all new inserts are routed