update documentation for 7.7 (#4653)

Author: Mpdreamz

docs/aggregations/bucket/parent/parent-aggregation-usage.asciidoc

@@ -47,7 +47,6 @@ new ParentAggregation("name_of_parent_agg", typeof(CommitActivity)) <1>
 }
 ----
 <1> `join` field is determined from the _child_ type. In this example, it is `CommitActivity`
-
 <2> sub-aggregations are on the type determined from the `join` field. In this example, a `Project` is a parent of `CommitActivity`
 
 [source,javascript]

docs/aggregations/writing-aggregations.asciidoc

@@ -232,7 +232,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
 
 [[handling-aggregate-response]]
@@ -276,6 +275,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/connection-pooling/building-blocks/connection-pooling.asciidoc

@@ -97,7 +97,6 @@ var pool = new CloudConnectionPool(cloudId, credentials); <2>
 var client = new ElasticClient(new ConnectionSettings(pool));
 ----
 <1> a username and password that can access Elasticsearch service on Elastic Cloud
-
 <2> `cloudId` is a value that can be retrieved from the Elastic Cloud web console
 
 This type of pool, like its parent the `SingleNodeConnectionPool`, is hardwired to opt out of

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

@@ -58,11 +58,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
@@ -101,9 +98,7 @@ audit = await audit.TraceUnexpectedException(
 );
 ----
 <1> calls on 9200 set up to throw a `HttpRequestException` or 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.
@@ -148,8 +143,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

@@ -81,7 +81,6 @@ var audit = new Auditor(() => VirtualClusterWith
 );
 ----
 <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
@@ -102,9 +101,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 attempts to deserialize the response body returned;
@@ -138,7 +135,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
@@ -173,6 +169,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/max-retries/respects-max-retry.asciidoc

@@ -84,7 +84,6 @@ audit = await audit.TraceCall(
 );
 ----
 <1> Set the maximum number of retries to 3
-
 <2> The client call trace returns an `MaxRetriesReached` audit after the initial attempt and the number of retries allowed
 
 In our previous example we simulated very fast failures, but in the real world, a call might take upwards of a second.

docs/client-concepts/connection-pooling/pinging/first-usage.asciidoc

@@ -92,13 +92,9 @@ 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. This fails
-
 <3> So we ping 9202. This _also_ fails
-
 <4> We then ping 9203 because we haven't used it before and it succeeds
-
 <5> Finally, we assert that the connection pool has two nodes that are marked as dead
 
 All nodes are pinged on first use, provided they are healthy
@@ -125,6 +121,5 @@ await audit.TraceCalls(
 );
 ----
 <1> Pings on nodes always succeed
-
 <2> A successful ping on each node
 

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

@@ -65,11 +65,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 
@@ -93,7 +90,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 
@@ -115,6 +111,5 @@ audit = await audit.TraceCall(
 );
 ----
 <1> disable ping and sniff
-
 <2> no ping or sniff before the call
 

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

@@ -140,9 +140,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 
@@ -193,6 +191,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/on-connection-failure.asciidoc

@@ -79,13 +79,9 @@ audit = await audit.TraceCalls(
 );
 ----
 <1> When the call fails on 9201, the following sniff succeeds and returns a new cluster state of healthy nodes. This cluster only has 3 nodes and the known masters are 9200 and 9202. A search on 9201 is setup to still fail once
-
 <2> After this second failure on 9201, another sniff will happen which returns a cluster state that no longer fails but looks completely different; It's now three nodes on ports 9210 - 9212, with 9210 and 9212 being master eligible.
-
 <3> We assert we do a sniff on our first known master node 9202 after the failed call on 9201
-
 <4> Our pool should now have three nodes
-
 <5> We assert we do a sniff on the first master node in our updated cluster
 
 ==== Sniffing after ping failure
@@ -151,11 +147,8 @@ audit = await audit.TraceCalls(
 );
 ----
 <1> We assert we do a sniff on our first known master node 9202
-
 <2> Our pool should now have three nodes
-
 <3> We assert we do a sniff on the first master node in our updated cluster
-
 <4> 9210 was already pinged after the sniff returned the new nodes
 
 ==== Client uses publish address