Fix indendation in doc.cs files which are excluded from the formatter

Author: Mpdreamz

src/Tests/Tests/Aggregations/ReservedAggregationNames.doc.cs

@@ -26,13 +26,13 @@ public class ReservedAggregationNames : DocumentationTestBase
 	{
 		public string[] Reserved => new []
 		{
-		    "score",
-            "value_as_string",
-            "keys",
-            "max_score"
+			"score",
+			"value_as_string",
+			"keys",
+			"max_score"
 		};
 
-        //hide
+		//hide
 		private TermsAggregation Terms(string name) => new TermsAggregation(name) {Field = "x"};
 
 		//hide

src/Tests/Tests/ClientConcepts/Certificates/WorkingWithCertificates.doc.cs

@@ -116,8 +116,8 @@ public AllowAllSslCertificatesApiTests(AllowAllCertificatesCluster cluster, Endp
 		 */
 		public class CertgenCaCluster : SslAndKpiXPackCluster
 		{
-            public CertgenCaCluster() : this(new SslAndKpiClusterConfiguration()) { }
-            public CertgenCaCluster(SslAndKpiClusterConfiguration configuration) : base(configuration) { }
+			public CertgenCaCluster() : this(new SslAndKpiClusterConfiguration()) { }
+			public CertgenCaCluster(SslAndKpiClusterConfiguration configuration) : base(configuration) { }
 			protected override ConnectionSettings ConnectionSettings(ConnectionSettings s) => s
 				.ServerCertificateValidationCallback(
 					CertificateValidations.AuthorityIsRoot(new X509Certificate(this.ClusterConfiguration.FileSystem.CaCertificate))

src/Tests/Tests/ClientConcepts/Connection/ConfigurationOptions.doc.cs

@@ -9,36 +9,36 @@ public class ConfigurationOptions
 	{
 		/**[[configuration-options]]
 		 * === Configuration options
-         *
-         * Connecting to Elasticsearch with <<elasticsearch-net-getting-started,Elasticsearch.Net>> and <<nest-getting-started,NEST>> is easy, but
+		 *
+		 * Connecting to Elasticsearch with <<elasticsearch-net-getting-started,Elasticsearch.Net>> and <<nest-getting-started,NEST>> is easy, but
 		 * it's entirely possible that you'd like to change the default connection behaviour. There are a number of configuration options available
 		 * on `ConnectionSettings` (and `ConnectionConfiguration` for Elasticsearch.Net) that can be used to control
 		 * how the clients interact with Elasticsearch.
-         *
-         * ==== Options on ConnectionConfiguration
-         *
-         * The following is a list of available connection configuration options on `ConnectionConfiguration`; since
-         * `ConnectionSettings` derives from `ConnectionConfiguration`, these options are available for both
-         * Elasticsearch.Net and NEST:
-         *
-         * :xml-docs: Elasticsearch.Net:ConnectionConfiguration`1
-         *
-         * ==== Options on ConnectionSettings
-         *
-         * The following is a list of available connection configuration options on `ConnectionSettings`:
-         *
-         * :xml-docs: Nest:ConnectionSettingsBase`1
 		 *
-         * Here's an example to demonstrate setting several configuration options using the low level client
+		 * ==== Options on ConnectionConfiguration
+		 *
+		 * The following is a list of available connection configuration options on `ConnectionConfiguration`; since
+		 * `ConnectionSettings` derives from `ConnectionConfiguration`, these options are available for both
+		 * Elasticsearch.Net and NEST:
+		 *
+		 * :xml-docs: Elasticsearch.Net:ConnectionConfiguration`1
+		 *
+		 * ==== Options on ConnectionSettings
+		 *
+		 * The following is a list of available connection configuration options on `ConnectionSettings`:
+		 *
+		 * :xml-docs: Nest:ConnectionSettingsBase`1
+		 *
+		 * Here's an example to demonstrate setting several configuration options using the low level client
 		 */
 		public void AvailableOptions()
 		{
 			var connectionConfiguration = new ConnectionConfiguration()
 				.DisableAutomaticProxyDetection()
 				.EnableHttpCompression()
 				.DisableDirectStreaming()
-                .PrettyJson()
-                .RequestTimeout(TimeSpan.FromMinutes(2));
+				.PrettyJson()
+				.RequestTimeout(TimeSpan.FromMinutes(2));
 
 			var lowLevelClient = new ElasticLowLevelClient(connectionConfiguration);
 
@@ -58,18 +58,18 @@ public void AvailableOptions()
 			var client = new ElasticClient(connectionSettings);
 
 			/**[NOTE]
-            * ====
-            *
-            * Basic Authentication credentials can alternatively be specified on the node URI directly
+			* ====
+			*
+			* Basic Authentication credentials can alternatively be specified on the node URI directly
 			*/
 			var uri = new Uri("http://username:password@localhost:9200");
 			var settings = new ConnectionConfiguration(uri);
 		}
-        /**
-        * but this can be awkward when using connection pooling with multiple nodes, especially when the connection pool
+		/**
+		* but this can be awkward when using connection pooling with multiple nodes, especially when the connection pool
 		* used is one that is capable of reseeding iteslf. For this reason, we'd recommend specifying credentials
 		* on `ConnectionSettings`.
-        *====
-        */
+		*====
+		*/
 	}
 }

src/Tests/Tests/ClientConcepts/Connection/ModifyingDefaultConnection.doc.cs

@@ -14,99 +14,99 @@
 
 namespace Tests.ClientConcepts.Connection
 {
-    /**[[modifying-default-connection]]
-     * === Modifying the default connection
-     *
-     * The client abstracts sending the request and creating a response behind `IConnection` and the default
-     * implementation uses
-     *
-     * - https://msdn.microsoft.com/en-us/library/system.net.webrequest(v=vs.110).aspx[`System.Net.WebRequest`] for Desktop CLR
-     * - https://msdn.microsoft.com/en-us/library/system.net.http.httpclient(v=vs.118).aspx[`System.Net.Http.HttpClient`] for Core CLR
-     *
-     * The reason for different implementations is that `WebRequest` and `ServicePoint` are not directly available
-     * on netstandard 1.3.
-     *
-     * The Desktop CLR implementation using `WebRequest` is the most mature implementation, having been tried and trusted
-     * in production since the beginning of NEST. For this reason, we aren't quite ready to it give up in favour of
-     * a `HttpClient` implementation across all CLR versions.
-     *
-     * In addition to production usage, there are also a couple of important toggles that are easy to set against a
-     * `ServicePoint` that are not possible to set as yet on `HttpClient`.
-     *
-     * Finally, another limitation is that `HttpClient` has no synchronous code paths, so supporting these means
-     * doing hacky async patches which definitely need time to bake.
-     *
-     * So why would you ever want to pass your own `IConnection`? Let's look at a couple of examples
-     *
-     */
-    public class ModifyingTheDefaultConnection
-    {
-        /**==== Using InMemoryConnection
-         *
-         * `InMemoryConnection` is an in-built `IConnection` that makes it easy to write unit tests against. It can be
-         * configured to respond with default response bytes, HTTP status code and an exception when a call is made.
-         *
-         * `InMemoryConnection` **doesn't actually send any requests or receive any responses from Elasticsearch**;
-         * requests are still serialized and the request bytes can be obtained on the response if `.DisableDirectStreaming` is
-         * set to `true` on the request or globally
-         */
-        public void InMemoryConnectionDefaultCtor()
-        {
-            var connection = new InMemoryConnection();
-            var connectionPool = new SingleNodeConnectionPool(new Uri("http://localhost:9200"));
-            var settings = new ConnectionSettings(connectionPool, connection);
-            var client = new ElasticClient(settings);
-        }
+	/**[[modifying-default-connection]]
+	 * === Modifying the default connection
+	 *
+	 * The client abstracts sending the request and creating a response behind `IConnection` and the default
+	 * implementation uses
+	 *
+	 * - https://msdn.microsoft.com/en-us/library/system.net.webrequest(v=vs.110).aspx[`System.Net.WebRequest`] for Desktop CLR
+	 * - https://msdn.microsoft.com/en-us/library/system.net.http.httpclient(v=vs.118).aspx[`System.Net.Http.HttpClient`] for Core CLR
+	 *
+	 * The reason for different implementations is that `WebRequest` and `ServicePoint` are not directly available
+	 * on netstandard 1.3.
+	 *
+	 * The Desktop CLR implementation using `WebRequest` is the most mature implementation, having been tried and trusted
+	 * in production since the beginning of NEST. For this reason, we aren't quite ready to it give up in favour of
+	 * a `HttpClient` implementation across all CLR versions.
+	 *
+	 * In addition to production usage, there are also a couple of important toggles that are easy to set against a
+	 * `ServicePoint` that are not possible to set as yet on `HttpClient`.
+	 *
+	 * Finally, another limitation is that `HttpClient` has no synchronous code paths, so supporting these means
+	 * doing hacky async patches which definitely need time to bake.
+	 *
+	 * So why would you ever want to pass your own `IConnection`? Let's look at a couple of examples
+	 *
+	 */
+	public class ModifyingTheDefaultConnection
+	{
+		/**==== Using InMemoryConnection
+		 *
+		 * `InMemoryConnection` is an in-built `IConnection` that makes it easy to write unit tests against. It can be
+		 * configured to respond with default response bytes, HTTP status code and an exception when a call is made.
+		 *
+		 * `InMemoryConnection` **doesn't actually send any requests or receive any responses from Elasticsearch**;
+		 * requests are still serialized and the request bytes can be obtained on the response if `.DisableDirectStreaming` is
+		 * set to `true` on the request or globally
+		 */
+		public void InMemoryConnectionDefaultCtor()
+		{
+			var connection = new InMemoryConnection();
+			var connectionPool = new SingleNodeConnectionPool(new Uri("http://localhost:9200"));
+			var settings = new ConnectionSettings(connectionPool, connection);
+			var client = new ElasticClient(settings);
+		}
 
-        /**
+		/**
 		 * Here we create a new `ConnectionSettings` by using the overload that takes a `IConnectionPool` and an `IConnection`.
 		 * We pass it an `InMemoryConnection` which, using the default parameterless constructor,
-         * will return 200 for everything and never actually perform any IO.
-         *
-         * Let's see a more complex example
+		 * will return 200 for everything and never actually perform any IO.
+		 *
+		 * Let's see a more complex example
 		 */
-        [U]
-        public void InMemoryConnectionOverloadedCtor()
-        {
-            var response = new
-            {
-                took = 1,
-                timed_out = false,
-                _shards = new
-                {
-                    total = 2,
-                    successful = 2,
-                    failed = 0
-                },
-                hits = new
-                {
-                    total = 25,
-                    max_score = 1.0,
-                    hits = Enumerable.Range(1, 25).Select(i => (object)new
-                    {
-                        _index = "project",
-                        _type = "project",
-                        _id = $"Project {i}",
-                        _score = 1.0,
-                        _source = new { name = $"Project {i}" }
-                    }).ToArray()
-                }
-            };
+		[U]
+		public void InMemoryConnectionOverloadedCtor()
+		{
+			var response = new
+			{
+				took = 1,
+				timed_out = false,
+				_shards = new
+				{
+					total = 2,
+					successful = 2,
+					failed = 0
+				},
+				hits = new
+				{
+					total = 25,
+					max_score = 1.0,
+					hits = Enumerable.Range(1, 25).Select(i => (object)new
+					{
+						_index = "project",
+						_type = "project",
+						_id = $"Project {i}",
+						_score = 1.0,
+						_source = new { name = $"Project {i}" }
+					}).ToArray()
+				}
+			};
 
-            var responseBytes = Encoding.UTF8.GetBytes(JsonConvert.SerializeObject(response));
-            var connection = new InMemoryConnection(responseBytes, 200); // <1> `InMemoryConnection` is configured to **always** return `responseBytes` along with a 200 HTTP status code
-            var connectionPool = new SingleNodeConnectionPool(new Uri("http://localhost:9200"));
-            var settings = new ConnectionSettings(connectionPool, connection).DefaultIndex("project");
-            var client = new ElasticClient(settings);
+			var responseBytes = Encoding.UTF8.GetBytes(JsonConvert.SerializeObject(response));
+			var connection = new InMemoryConnection(responseBytes, 200); // <1> `InMemoryConnection` is configured to **always** return `responseBytes` along with a 200 HTTP status code
+			var connectionPool = new SingleNodeConnectionPool(new Uri("http://localhost:9200"));
+			var settings = new ConnectionSettings(connectionPool, connection).DefaultIndex("project");
+			var client = new ElasticClient(settings);
 
-	        var searchResponse = client.Search<Project>(s => s.MatchAll());
+			var searchResponse = client.Search<Project>(s => s.MatchAll());
 
-	        /**
-	         * We can now assert that the `searchResponse` is valid and contains documents deserialized
-	         * from our fixed `InMemoryConnection` response
-	         */
-            searchResponse.ShouldBeValid();
-            searchResponse.Documents.Count.Should().Be(25);
-        }
-    }
+			/**
+			 * We can now assert that the `searchResponse` is valid and contains documents deserialized
+			 * from our fixed `InMemoryConnection` response
+			 */
+			searchResponse.ShouldBeValid();
+			searchResponse.Documents.Count.Should().Be(25);
+		}
+	}
 }

src/Tests/Tests/ClientConcepts/ConnectionPooling/BuildingBlocks/ConnectionPooling.doc.cs

@@ -14,22 +14,22 @@ public class ConnectionPooling
 		 * === Connection pools
 		 * Connection pooling is the internal mechanism that takes care of registering what nodes there are in the cluster and which
 		 * NEST can use to issue client calls on.
-         *
-         * [IMPORTANT]
-         * --
-         * Despite the name, a connection pool in NEST is **not** like connection pooling that you may be familiar with from
-         * https://msdn.microsoft.com/en-us/library/bb399543(v=vs.110).aspx[interacting with a database using ADO.Net]; for example,
-         * a connection pool in NEST is **not** responsible for managing an underlying pool of TCP connections to Elasticsearch,
-         * this is https://blogs.msdn.microsoft.com/adarshk/2005/01/02/understanding-system-net-connection-management-and-servicepointmanager/[handled by the ServicePointManager in Desktop CLR].
-         * --
-         *
-         * So, what is a connection pool in NEST responsible for? It is responsible for managing the nodes in an Elasticsearch
-         * cluster to which a connection can be made and there is one instance of an `IConnectionPool` associated with an
-         * instance of `ConnectionSettings`. Since a <<lifetimes,single client and connection settings instance is recommended for the
-         * life of the application>>, the lifetime of a single connection pool instance will also be bound to the lifetime
-         * of the application.
-         *
-         * There are four types of connection pool
+		 *
+		 * [IMPORTANT]
+		 * --
+		 * Despite the name, a connection pool in NEST is **not** like connection pooling that you may be familiar with from
+		 * https://msdn.microsoft.com/en-us/library/bb399543(v=vs.110).aspx[interacting with a database using ADO.Net]; for example,
+		 * a connection pool in NEST is **not** responsible for managing an underlying pool of TCP connections to Elasticsearch,
+		 * this is https://blogs.msdn.microsoft.com/adarshk/2005/01/02/understanding-system-net-connection-management-and-servicepointmanager/[handled by the ServicePointManager in Desktop CLR].
+		 * --
+		 *
+		 * So, what is a connection pool in NEST responsible for? It is responsible for managing the nodes in an Elasticsearch
+		 * cluster to which a connection can be made and there is one instance of an `IConnectionPool` associated with an
+		 * instance of `ConnectionSettings`. Since a <<lifetimes,single client and connection settings instance is recommended for the
+		 * life of the application>>, the lifetime of a single connection pool instance will also be bound to the lifetime
+		 * of the application.
+		 *
+		 * There are four types of connection pool
 		 *
 		 * - <<single-node-connection-pool,SingleNodeConnectionPool>>
 		 * - <<static-connection-pool,StaticConnectionPool>>
@@ -201,7 +201,7 @@ [U] public void SniffingSortedSticky()
 			var pool = new StickySniffingConnectionPool(uris, n =>
 				(n.ClientNode ? 10 : 0)
 				+ (n.Settings.TryGetValue("node.attr.rack_id", out var rackId)
-				   		&& rackId.ToString() == "rack_one" ? 10 : 0));
+						&& rackId.ToString() == "rack_one" ? 10 : 0));
 
 			pool.SupportsReseeding.Should().BeTrue();
 			pool.SupportsPinging.Should().BeTrue();