Fix broken docs and polish

docs/modules/ROOT/pages/discovery-client.adoc

@@ -48,7 +48,7 @@ HTTP Based `DiscoveryClient`
 ====
 
 NOTE: `spring-cloud-starter-kubernetes-discoveryclient` is designed to be used with the
-<<spring-cloud-kubernetes-discoveryserver, Spring Cloud Kubernetes DiscoveryServer>>.
+xref:spring-cloud-kubernetes-discoveryserver.adoc[Spring Cloud Kubernetes DiscoveryServer].
 
 To enable loading of the `DiscoveryClient`, add `@EnableDiscoveryClient` to the according configuration or application class, as the following example shows:
 

docs/modules/ROOT/pages/getting-started.adoc

@@ -32,7 +32,7 @@ use and use the starters for that library only.
     <artifactId>spring-cloud-starter-kubernetes-client</artifactId>
 </dependency>
 ----
-| <<DiscoveryClient for Kubernetes,Discovery Client>> implementation that
+| xref:discovery-client.adoc[Discovery Client] implementation that
 resolves service names to Kubernetes Services.
 
 | [source,xml]

docs/modules/ROOT/pages/kubernetes-awareness.adoc

@@ -30,7 +30,8 @@ If it is needed to explicitly enable or disable this awareness, use `spring.main
 
 - Another breaking change is the additional `list` verb needed for loading configmaps/secrets. For example:
 
-```
+[source,yaml]
+----
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
@@ -39,7 +40,7 @@ rules:
   - apiGroups: ["", "extensions", "apps", "discovery.k8s.io"]
     resources: ["configmaps", "pods", "services", "endpoints", "secrets", "endpointslices"]
     verbs: ["get", "list", "watch"]
-```
+----
 
 [[kubernetes-profile-autoconfiguration]]
 == Kubernetes Profile Autoconfiguration

docs/modules/ROOT/pages/property-source-config/configmap-propertysource.adoc

@@ -57,7 +57,7 @@ An example should make a lot more sense. Let's suppose that `spring.application.
 we have a single active profile called `k8s`. For a configuration as below:
 
 
-[source]
+[source,yaml]
 ----
 kind: ConfigMap
 apiVersion: v1
@@ -92,7 +92,7 @@ The order of loading properties is a as follows:
 This means that profile based sources take precedence over non-profile based sources (just like in a vanilla Spring app); and plain properties take precedence over both profile and non-profile based sources. Here is an example:
 
 ====
-[source]
+[source,yaml]
 ----
 kind: ConfigMap
 apiVersion: v1
@@ -101,7 +101,7 @@ metadata:
 data:
   my-app-k8s.yaml: |-
     key1=valueA
-	key2=valueB
+    key2=valueB
   my-app.yaml: |-
     key1=valueC
     key2=valueA
@@ -318,13 +318,13 @@ spec:
     metadata:
       labels:
         app: deployment-name
-	spec:
-		containers:
-		- name: container-name
-		  image: your-image
-		  env:
-		  - name: SPRING_PROFILES_ACTIVE
-			value: "development"
+    spec:
+      containers:
+        - name: container-name
+          image: your-image
+          env:
+            - name: SPRING_PROFILES_ACTIVE
+              value: "development"
 ----
 
 You could run into a situation where there are multiple configs maps that have the same property names. For example:
@@ -447,7 +447,7 @@ will result in three properties being generated:
 The same way you configure a prefix for configmaps, you can do it for secrets also; both for secrets that are based on name
 and the ones based on labels. For example:
 
-[source.yaml]
+[source,yaml]
 ----
 spring:
   application:
@@ -479,7 +479,7 @@ will be the names of all secrets found for those particular labels.
 
 One more thing to bear in mind is that we support `prefix` per _source_, not per secret. The easiest way to explain this is via an example:
 
-[source.yaml]
+[source,yaml]
 ----
 spring:
   application:
@@ -556,15 +556,16 @@ This behavior is controlled by the `spring.cloud.kubernetes.config.paths` proper
 addition to or instead of the mechanism described earlier.
 `spring.cloud.kubernetes.config.paths` expects a List of full paths to each property file, because directories are not being recursively parsed. For example:
 
-```
+[source,yaml]
+----
 spring:
   cloud:
     kubernetes:
       config:
         paths:
           - /tmp/application.properties
           - /var/application.yaml
-```
+----
 
 NOTE:  If you use `spring.cloud.kubernetes.config.paths` or `spring.cloud.kubernetes.secrets.path` the automatic reload
 functionality will not work.  You will need to make a `POST` request to the `/actuator/refresh` endpoint or
@@ -602,4 +603,3 @@ by setting `spring.cloud.kubernetes.config.retry.enabled=false`.
 | `spring.cloud.kubernetes.config.retry.max-interval`     | `Long`    | `2000`                       | Maximum interval for backoff.
 | `spring.cloud.kubernetes.config.retry.multiplier`       | `Double`  | `1.1`                        | Multiplier for next interval.
 |===
-

docs/modules/ROOT/pages/property-source-config/propertysource-reload.adoc

@@ -2,7 +2,7 @@
 = `PropertySource` Reload
 
 WARNING:  This functionality has been deprecated in the 2020.0 release.  Please see
-the xref:spring-cloud-kubernetes-configuration-watcher.adoc#spring-cloud-kubernetes-configuration-watcher[Spring Cloud Kubernetes Configuration Watcher]
+the xref:spring-cloud-kubernetes-configuration-watcher.adoc[Spring Cloud Kubernetes Configuration Watcher]
 controller for an alternative way to achieve the same functionality.
 
 Some applications may need to detect changes on external property sources and update their internal status to reflect the new configuration.
@@ -98,4 +98,3 @@ The `view` role on the service account is required in order to listen for config
 You can configure the polling period by using the `spring.cloud.kubernetes.reload.period` property and defaults to 15 seconds.
 It requires the same role as the monitored property source.
 This means, for example, that using polling on file-mounted secret sources does not require particular privileges.
-