Docs: Removed xref to multi fields topic that has been removed.

Author: debadair

src/Tests/ClientConcepts/HighLevel/Inference/FieldInference.doc.cs

@@ -1,4 +1,4 @@
-using System;
+using System;
 using System.Collections.Generic;
 using System.Linq;
 using System.Linq.Expressions;
@@ -233,7 +233,7 @@ public void ComplexFieldNameExpressions()
 			Expect("metadata.var.created").WhenSerializing(Field<Project>(p => p.Metadata[variable].Created));
 
 			/**
-			* If you are using Elasticearch's {ref_current}/_multi_fields.html[multi_fields], which you really should as they allow
+			* If you are using Elasticearch's multi fields, which you really should as they allow
 			* you to analyze a string in a number of different ways, these __"virtual"__ sub fields
 			* do not always map back on to your POCO. By calling `.Suffix()` on expressions, you describe the sub fields that
 			* should be mapped and <<auto-map, how they are mapped>>

src/Tests/ClientConcepts/HighLevel/Inference/PropertyInference.doc.cs

@@ -1,4 +1,4 @@
-using System;
+using System;
 using System.Linq.Expressions;
 using Nest;
 using Tests.Framework;
@@ -25,9 +25,9 @@ public PropertyNames(IndexingCluster cluster) : base(cluster)
 
 		/**=== Appending suffixes to a Lambda expression body
 		 * Suffixes can be appended to the body of a lambda expression, useful in cases where
-		 * you have a POCO property mapped as a {ref_current}/_multi_fields.html[multi_field]
+		 * you have a POCO property mapped as a multi field
 		 * and want to use strongly typed access based on the property, yet append a suffix to the
-		 * generated field name in order to access a particular `multi_field`.
+		 * generated field name in order to access a particular multi field.
 		 *
 		 * The `.Suffix()` extension method can be used for this purpose and when serializing expressions suffixed
 		 * in this way, the serialized field name resolves to the last token
@@ -52,7 +52,7 @@ [U] public void PropertyNamesAreResolvedToLastTokenUsingAppendSuffix()
 
 		/**=== Naming conventions
 		 * Currently, the name of a field cannot contain a `.` in Elasticsearch due to the potential for ambiguity with
-		 * a field that is mapped as a {ref_current}/_multi_fields.html[multi_field].
+		 * a field that is mapped as a multi field.
 		 *
 		 * In these cases, NEST allows the call to go to Elasticsearch, deferring the naming conventions to the server side and,
 		 * in the case of a `.` in a field name, a `400 Bad Response` is returned with a server error indicating the reason