update docs

Author: Mpdreamz

docs/aggregations/writing-aggregations.asciidoc

@@ -230,7 +230,6 @@ return s => s
         );
 ----
 <1> a list of aggregation functions to apply
-
 <2> Using LINQ's `Aggregate()` function to accumulate/apply all of the aggregation functions
 
 [[aggs-vs-aggregations]]
@@ -278,6 +277,5 @@ var maxPerChild = childAggregation.Max("max_per_child");
 maxPerChild.Should().NotBeNull(); <2>
 ----
 <1> Do something with the average per child. Here we just assert it's not null
-
 <2> Do something with the max per child. Here we just assert it's not null
 

docs/client-concepts/certificates/working-with-certificates.asciidoc

@@ -152,11 +152,8 @@ public class PkiCluster : CertgenCaCluster
 }
 ----
 <1> Set the client certificate on `ConnectionSettings`
-
 <2> The path to the `.cer` file
-
 <3> The path to the `.key` file
-
 <4> The password for the private key
 
 Or per request on `RequestConfiguration` which will take precedence over the ones defined on `ConnectionConfiguration`

docs/client-concepts/connection-pooling/exceptions/unexpected-exceptions.asciidoc

@@ -60,11 +60,8 @@ audit = await audit.TraceUnexpectedException(
 );
 ----
 <1> set up a cluster with 10 nodes
-
 <2> where node 2 on port 9201 always throws an exception
-
 <3> The first call to 9200 returns a healthy response
-
 <4> ...but the second call, to 9201, returns a bad response
 
 Sometimes, an unexpected exception happens further down in the pipeline. In this scenario, we
@@ -103,9 +100,7 @@ audit = await audit.TraceUnexpectedException(
 );
 ----
 <1> calls on 9200 set up to throw a `WebException`
-
 <2> calls on 9201 set up to throw an `Exception`
-
 <3> Assert that the audit trail for the client call includes the bad response from 9200 and 9201
 
 An unexpected hard exception on ping and sniff is something we *do* try to recover from and failover to retrying on the next node.
@@ -150,8 +145,6 @@ audit = await audit.TraceUnexpectedException(
 );
 ----
 <1> `InnerException` is the exception that brought the request down
-
 <2> The hard exception that happened on ping is still available though
-
 <3> An exception can be hard to relate back to a point in time, so the exception is also available on the audit trail
 

docs/client-concepts/connection-pooling/exceptions/unrecoverable-exceptions.asciidoc

@@ -68,7 +68,6 @@ var audit = new Auditor(() => Framework.Cluster
 );
 ----
 <1> Always succeed on ping
-
 <2> ...but always fail on calls with a 401 Bad Authentication response
 
 Now, let's make a client call. We'll see that the first audit event is a successful ping
@@ -89,9 +88,7 @@ audit = await audit.TraceElasticsearchException(
 );
 ----
 <1> First call results in a successful ping
-
 <2> Second call results in a bad response
-
 <3> The reason for the bad response is Bad Authentication
 
 When a bad authentication response occurs, the client does not attempt to deserialize the response body returned;
@@ -125,7 +122,6 @@ audit = await audit.TraceElasticsearchException(
 );
 ----
 <1> Always return a 401 bad response with a HTML response on client calls
-
 <2> Assert that the response body bytes are null
 
 Now in this example, by turning on `DisableDirectStreaming()` on `ConnectionSettings`, we see the same behaviour exhibited
@@ -158,6 +154,5 @@ audit = await audit.TraceElasticsearchException(
 );
 ----
 <1> Response bytes are set on the response
-
 <2> Assert that the response contains `"nginx/"`
 

docs/client-concepts/connection-pooling/request-overrides/disable-sniff-ping-per-request.asciidoc

@@ -67,11 +67,8 @@ audit = await audit.TraceCalls(
 );
 ----
 <1> disable sniffing
-
 <2> first call is a successful ping
-
 <3> sniff on startup call happens here, on the second call
-
 <4> No sniff on startup again
 
 Now, let's disable pinging on the request 
@@ -95,7 +92,6 @@ audit = await audit.TraceCall(
 );
 ----
 <1> disable ping
-
 <2> No ping after sniffing
 
 Finally, let's demonstrate disabling both sniff and ping on the request 
@@ -117,6 +113,5 @@ audit = await audit.TraceCall(
 );
 ----
 <1> diable ping and sniff
-
 <2> no ping or sniff before the call
 

docs/client-concepts/connection-pooling/round-robin/skip-dead-nodes.asciidoc

@@ -142,9 +142,7 @@ await audit.TraceCalls(
 );
 ----
 <1> The first call goes to 9200 which succeeds
-
 <2> The 2nd call does a ping on 9201 because its used for the first time. It fails so we wrap over to node 9202
-
 <3> The next call goes to 9203 which fails so we should wrap over
 
 A cluster with 2 nodes where the second node fails on ping 
@@ -194,6 +192,5 @@ await audit.TraceCalls(
 );
 ----
 <1> All the calls fail
-
 <2> After all our registered nodes are marked dead we want to sample a single dead node each time to quickly see if the cluster is back up. We do not want to retry all 4 nodes
 

docs/client-concepts/connection-pooling/sniffing/role-detection.asciidoc

@@ -140,7 +140,6 @@ var audit = new Auditor(() => Framework.Cluster
 };
 ----
 <1> Before the sniff, assert we only see three master only nodes
-
 <2> After the sniff, assert we now know about the existence of 20 nodes.
 
 After the sniff has happened on 9200 before the first API call, assert that the subsequent API
@@ -221,9 +220,7 @@ var audit = new Auditor(() => Framework.Cluster
 };
 ----
 <1> for testing simplicity, disable pings
-
 <2> We only want to execute API calls to nodes in rack_one
-
 <3> After sniffing on startup, assert that the pool of nodes that the client will execute API calls against only contains the three nodes that are in `rack_one`
 
 With the cluster set up, assert that the sniff happens on 9200 before the first API call
@@ -300,8 +297,6 @@ await audit.TraceUnexpectedElasticsearchException(new ClientCall
 });
 ----
 <1> The audit trail indicates a sniff for the very first time on startup
-
 <2> The sniff succeeds because the node predicate is ignored when sniffing
-
 <3> when trying to do an actual API call however, the predicate prevents any nodes from being attempted
 

docs/client-concepts/high-level/analysis/writing-analyzers.asciidoc

@@ -105,7 +105,6 @@ var createIndexResponse = client.CreateIndex("my-index", c => c
 );
 ----
 <1> Pre-defined list of English stopwords within Elasticsearch
-
 <2> Use the `standard_english` analyzer configured
 
 [source,javascript]
@@ -271,7 +270,6 @@ var createIndexResponse = client.CreateIndex("questions", c => c
 );
 ----
 <1> Use an analyzer at index time that strips HTML tags
-
 <2> Use an analyzer at search time that does not strip HTML tags
 
 With this in place, the text of a question body will be analyzed with the `index_question` analyzer

docs/client-concepts/high-level/getting-started.asciidoc

@@ -109,7 +109,6 @@ var indexResponse = client.Index(person); <1>
 var asyncIndexResponse = await client.IndexAsync(person); <2>
 ----
 <1> synchronous method that returns an `IIndexResponse`
-
 <2> asynchronous method that returns a `Task<IIndexResponse>` that can be awaited
 
 NOTE: All methods available within NEST are exposed as both synchronous and asynchronous versions,

docs/client-concepts/high-level/inference/field-inference.asciidoc

@@ -474,13 +474,9 @@ class Precedence
 }
 ----
 <1> Even though this property has a NEST property mapping _and_ a `JsonProperty` attribute, We are going to provide a hard rename for it on ConnectionSettings later that should win.
-
 <2> This property has both a NEST attribute and a `JsonProperty`, NEST should win.
-
 <3> We should take the json property into account by itself
-
 <4> This property we are going to special case in our custom serializer to resolve to ask
-
 <5> We are going to register a DefaultFieldNameInferrer on ConnectionSettings that will uppercase all properties.
 
 Here we create a custom serializer that renames any property named `AskSerializer` to `ask`