Improvements to documentation

Respect the indentation in the source
Allow all of <,>,&lt; and &gt; within multiline comments

Author: russcam

docs/asciidoc/Aggregations/Bucket/Children/ChildrenAggregationMapping.doc.asciidoc

@@ -9,7 +9,7 @@ var createProjectIndex = TestClient.GetClient().CreateIndex(typeof(Project), c =
 	.Mappings(map=>map
 		.Map<Project>(m=>m.AutoMap())
 		.Map<CommitActivity>(m=>m
-.Parent<Project>()
+			.Parent<Project>()
 		)
 	)
 );

docs/asciidoc/ClientConcepts/ConnectionPooling/BuildingBlocks/ConnectionPooling.Doc.asciidoc

@@ -2,11 +2,13 @@
 Connection pooling is the internal mechanism that takes care of registering what nodes there are in the cluster and which
 we can use to issue client calls on.
 
+
 == SingleNodeConnectionPool
 The simplest of all connection pools, this takes a single `Uri` and uses that to connect to elasticsearch for all the calls
 It doesn't opt in to sniffing and pinging behavior, and will never mark nodes dead or alive. The one `Uri` it holds is always
 ready to go.
 
+
 [source, csharp]
 ----
 var uri = new Uri("http://localhost:9201");
@@ -62,6 +64,7 @@ client.ConnectionSettings.ConnectionPool.Should().BeOfType<SingleNodeConnectionP
 The static connection pool is great if you have a known small sized cluster and do no want to enable
 sniffing to find out the cluster topology.
 
+
 [source, csharp]
 ----
 var uris = Enumerable.Range(9200, 5).Select(p => new Uri("http://localhost:" + p));
@@ -109,6 +112,7 @@ client.ConnectionSettings.ConnectionPool.Should().BeOfType<StaticConnectionPool>
 A subclass of StaticConnectionPool that allows itself to be reseeded at run time.
 It comes with a very minor overhead of a `ReaderWriterLockSlim` to ensure thread safety.
 
+
 [source, csharp]
 ----
 var uris = Enumerable.Range(9200, 5).Select(p => new Uri("http://localhost:" + p));

docs/asciidoc/ClientConcepts/ConnectionPooling/BuildingBlocks/DateTimeProviders.Doc.asciidoc

@@ -4,6 +4,7 @@ Not typically something you'll have to pass to the client but all calls to `Syst
 in the client have been abstracted by `IDateTimeProvider`. This allows us to unit test timeouts and clusterfailover
 in run time not being bound to wall clock time.
 
+
 [source, csharp]
 ----
 var dateTimeProvider = DateTimeProvider.Default;
@@ -14,10 +15,12 @@ dates are always returned in UTC
 ----
 dateTimeProvider.Now().Should().BeCloseTo(DateTime.UtcNow);
 ----
+
 Another responsibility of this interface is to calculate the time a node has to be taken out of rotation
 based on the number of attempts to revive it. For very advanced use cases, this might be something of interest
 to provide a custom implementation for.
 
+
 [source, csharp]
 ----
 var dateTimeProvider = DateTimeProvider.Default;

docs/asciidoc/ClientConcepts/ConnectionPooling/BuildingBlocks/KeepingTrackOfNodes.Doc.asciidoc

@@ -1,6 +1,7 @@
 = Keeping track of nodes
 
 
+
 [source, csharp]
 ----
 var node = new Node(new Uri("http://localhost:9200"));
@@ -26,6 +27,7 @@ node.IsResurrected.Should().BeTrue();
 When instantiating your connection pool you could switch these to false to initialize the client to
 a known cluster topology.
 
+
 passing a node with a path should be preserved. Sometimes an elasticsearch node lives behind a proxy 
 
 [source, csharp]
@@ -64,6 +66,7 @@ node.IsAlive.Should().BeTrue();
 every time a node is marked dead the number of attempts should increase
 and the passed datetime should be exposed.
 
+
 [source, csharp]
 ----
 var deadUntil = DateTime.Now.AddMinutes(1);

docs/asciidoc/ClientConcepts/ConnectionPooling/BuildingBlocks/RequestPipelines.doc.asciidoc

@@ -2,6 +2,7 @@
 Every request is executed in the context of `RequestPipeline` when using the default `ITransport` implementation.
 
 
+
 [source, csharp]
 ----
 var settings = TestClient.CreateSettings();
@@ -119,6 +120,7 @@ sniffingPipeline.StaleClusterState.Should().BeTrue();
 A request pipeline also checks whether the overall time across multiple retries exceeds the request timeout
 See the maxretry documentation for more details, here we assert that our request pipeline exposes this propertly
 
+
 [source, csharp]
 ----
 var dateTime = new TestableDateTimeProvider();

docs/asciidoc/ClientConcepts/ConnectionPooling/BuildingBlocks/Transports.Doc.asciidoc

@@ -1,9 +1,11 @@
 = Transports
+
 The `ITransport` interface can be seen as the motor block of the client. It's interface is deceitfully simple.
 It's ultimately responsible from translating a client call to a response. If for some reason you do not agree with the way we wrote
 the internals of the client, by implementing a custom `ITransport`, you can circumvent all of it and introduce your own.
 
 
+
 Transport is generically typed to a type that implements IConnectionConfigurationValues 
 This is the minimum ITransport needs to report back for the client to function.
 e.g in the low level client, transport is instantiated like this:

docs/asciidoc/ClientConcepts/ConnectionPooling/Exceptions/UnexpectedExceptions.doc.asciidoc

@@ -4,6 +4,7 @@ out the client as an UnexpectedElasticsearchClientException, regardless whether
 An IConnection is in charge of knowning what exceptions it can recover from or not. The default IConnection that is based on WebRequest can and
 will recover from WebExceptions but others will be grounds for immediately exiting the pipeline.
 
+
 [source, csharp]
 ----
 var audit = new Auditor(() => Framework.Cluster
@@ -33,12 +34,14 @@ e.FailureReason.Should().Be(PipelineFailure.Unexpected);
 e.InnerException.Should().NotBeNull();
 e.InnerException.Message.Should().Be("boom!");
 ----
+
 Sometimes an unexpected exception happens further down in the pipeline, this is why we
 wrap them inside an UnexpectedElasticsearchClientException so that information about where
 in the pipeline the unexpected exception is not lost, here a call to 9200 fails using a webexception.
 It then falls over to 9201 which throws an hard exception from within IConnection. We assert that we
 can still see the audit trail for the whole coordinated request.
 
+
 [source, csharp]
 ----
 var audit = new Auditor(() => Framework.Cluster
@@ -68,10 +71,12 @@ e.FailureReason.Should().Be(PipelineFailure.Unexpected);
 e.InnerException.Should().NotBeNull();
 e.InnerException.Message.Should().Be("boom!");
 ----
+
 An unexpected hard exception on ping and sniff is something we *do* try to revover from and failover.
 Here pinging nodes on first use is enabled and 9200 throws on ping, we still fallover to 9201's ping succeeds.
 However the client call on 9201 throws a hard exception we can not recover from
 
+
 [source, csharp]
 ----
 var audit = new Auditor(() => Framework.Cluster

docs/asciidoc/ClientConcepts/ConnectionPooling/Exceptions/UnrecoverableExceptions.doc.asciidoc

@@ -4,6 +4,7 @@ By default the client won't throw on any ElasticsearchClientException but return
 You can configure the client to throw using ThrowExceptions() on ConnectionSettings. The following test
 both a client that throws and one that returns an invalid response with an `.OriginalException` exposed
 
+
 [source, csharp]
 ----
 var recoverablExceptions = new[]

docs/asciidoc/ClientConcepts/ConnectionPooling/Failover/FallingOver.doc.asciidoc

@@ -2,6 +2,7 @@
 When using connection pooling and the pool has sufficient nodes a request will be retried if
 the call to a node throws an exception or returns a 502 or 503
 
+
 [source, csharp]
 ----
 var audit = new Auditor(() => Framework.Cluster
@@ -21,6 +22,7 @@ audit = await audit.TraceCall(
 502 Bad Gateway
 Will be treated as an error that requires retrying
 
+
 [source, csharp]
 ----
 var audit = new Auditor(() => Framework.Cluster
@@ -40,6 +42,7 @@ audit = await audit.TraceCall(
 503 Service Unavailable
 Will be treated as an error that requires retrying
 
+
 [source, csharp]
 ----
 var audit = new Auditor(() => Framework.Cluster
@@ -56,8 +59,10 @@ audit = await audit.TraceCall(
 				}
 			);
 ----
+
 If a call returns a valid http status code other then 502/503 the request won't be retried.
 
+
 [source, csharp]
 ----
 var audit = new Auditor(() => Framework.Cluster

docs/asciidoc/ClientConcepts/ConnectionPooling/MaxRetries/RespectsMaxRetry.doc.asciidoc

@@ -3,6 +3,7 @@ By default retry as many times as we have nodes. However retries still respect t
 Meaning if you have a 100 node cluster and a request timeout of 20 seconds we will retry as many times as we can
 but give up after 20 seconds
 
+
 [source, csharp]
 ----
 var audit = new Auditor(() => Framework.Cluster
@@ -27,9 +28,11 @@ audit = await audit.TraceCall(
 				}
 			);
 ----
+
 When you have a 100 node cluster you might want to ensure a fixed number of retries.
 Remember that the actual number of requests is initial attempt + set number of retries
 
+
 [source, csharp]
 ----
 var audit = new Auditor(() => Framework.Cluster
@@ -54,6 +57,7 @@ In our previous test we simulated very fast failures, in the real world a call m
 Here we simulate a particular heavy search that takes 10 seconds to fail, our Request timeout is set to 20 seconds.
 In this case it does not make sense to retry our 10 second query on 10 nodes. We should try it twice and give up before a third call is attempted
 
+
 [source, csharp]
 ----
 var audit = new Auditor(() => Framework.Cluster
@@ -77,6 +81,7 @@ Here we simulate calls taking 3 seconds, a request time out of 2 and an overall
 We should see 5 attempts to perform this query, testing that our request timeout cuts the query off short and that our max retry timeout of 10
 wins over the configured request timeout
 
+
 [source, csharp]
 ----
 var audit = new Auditor(() => Framework.Cluster
@@ -100,6 +105,7 @@ audit = await audit.TraceCall(
 
 If your retry policy expands beyond available nodes we won't retry the same node twice
 
+
 [source, csharp]
 ----
 var audit = new Auditor(() => Framework.Cluster
@@ -122,6 +128,7 @@ This makes setting any retry setting on a single node connection pool a NOOP, th
 Connection pooling and connection failover is about trying to fail sanely whilst still utilizing available resources and
 not giving up on the fail fast principle. It's *NOT* a mechanism for forcing requests to succeed.
 
+
 [source, csharp]
 ----
 var audit = new Auditor(() => Framework.Cluster