Update formatting

Signed-off-by: Mayank Shah <mayankshah1614@gmail.com>

design/0003-conformance-validation.md

@@ -274,7 +274,7 @@ The conformance test suite is intended to be run against an installation of Link
 
 This section includes write ups regarding testing methodologies for some primary features:
 
-**1. Automatic Proxy Injection**
+#### 1. Automatic Proxy Injection
 
 Proxy injection process works by adding a `linkerd.io/inject: enabled` annotation to pod template / namespace. This triggers an admission webhook that injects the `linkerd-proxy` container to the targeted deployments. This process shall be tested in 7 steps:
 
@@ -296,7 +296,7 @@ Alternatively, as users may want to test for conformance on their own sample app
 
 - Ensure that the pods no longer have the `linkerd-init` and `linkerd-proxy` containers.
 
-**2. `tap` extension API server**
+#### 2. `tap` extension API server
 
 Some custom Kubernetes clusters don't always have the aggregation layer configured, causing the tap service which is an extension API server to fail.
 - Issue a `check` command - `linkerd -n <ns> check --pre -o json`
@@ -332,7 +332,7 @@ This test will work by issuing the `linkerd tap` cmd on various resources of the
 - Issue `linkerd routes` cmd
 - Validate the returned output by counting instances of desired route substrings using `strings.Count`
 
-**4. Ingress**
+#### 4. Ingress
 
 It is essential to test ingress to ensure that the ingress controller re-writes incoming headers to the internal service name. This process ensures that service discovery is working. This test shall include deploying various types of ingress controllers (Nginx, Traefik and Ambassador) :
 
@@ -374,14 +374,14 @@ $ kubectl get svc --all-namespaces \
 - Issue a curl cmd on the external IP to check if desired response is returned. This shall be done by wrapping the curl bash cmd as a method in Golang using `command.exec()`.
 - On failure of this test suite, useful debugging information shall be displayed - such as the output of attempting to fetch an external IP, or the output of `cURL`. Further, users shall be allowed to not have these resources destroyed on test failure.
 
-**5. Data plane proxy health checks**
+#### 5. Data plane proxy health checks
 
 - Issue a `check` command - `linkerd -n <ns> check --proxy -o json`
 - From the output JSON, under `"categoryName" : "linkerd-data-plane"`, verify if the `result` of each check under the `checks` array shows `success`.
 - Make a `GET` request to the `linkerd-proxy` containers (of each of the pods) at the `/metrics` (Liveness probe) and `/ready` (Readiness probes) to ensure that they are reachable.
 - From the `linkerd-proxy` container of each of the pods, check for 503 errors.
 
-**6. Retries and Timeouts**
+#### 6. Retries and Timeouts
 
 - Some of the code from the existing integration tests may be reused for this section. In particular, we're looking for `test/serviceprofiles/serviceprofiles_test.go`
 - After verifying if our _emojivoto_ deployments and services are up and running, a `linkerd routes` cmd shall be issued, and the returned routes are compared to the expected routes. We shall pick deployments that have an edge, For e.g - `web` and `voting`
@@ -406,19 +406,19 @@ Further, following up with [this comment](https://github.com/linkerd/linkerd2/is
 This way, users shall be allowed to monitor the occurences of retries and timeouts.  
 
 
-**7. Distributed Tracing (optional)**
+#### 7. Distributed Tracing (optional)
 
 Currently there exist some integration tests for _Distributed tracing_. Applications meshed with Linkerd can be easily tested for this by making a `GET` request on the Jaeger backend at `/api/traces` endpoint on port 16686. (lookback and service parameters shall be made configurable via CLI flags)
 
-**8. Canary Release (optional)**
+#### 8. Canary Release (optional)
 
 Once a Canary Release is configured, an updated may be triggered. The metrics from the `stat` cmd may be verified to ensure that this feature is configured correctly.
 
 
 ### Protocol related tests
 It is important to note that these tests could fail if the `workloadNamespace` property of the test config is set to anything other than the default (moviechat/emojivoto) application.
 
-**1. gRPC Streaming**
+#### 1. gRPC Streaming
 
 The movie chat application / emojivoto shall leverage gRPC streaming. It is essential to ensure that streaming services are not affected by Linkerd - under normal conditions as well as during stress tests (if any).
 
@@ -428,7 +428,7 @@ The movie chat application / emojivoto shall leverage gRPC streaming. It is esse
 **Good to have:**  
 The logs gathered by Sonobuoy may also show metrics such as `rps` and the different latencies.
 
-**2. Websockets**
+#### 2. Websockets
 
 Similar to gRPC streaming, it is essential to check if Linkerd does not break services that utilise websocket connections. In our sample application, we create a chat server that handles socket connections to and fro from the web application. To test this, we can ping the websocket endpoints using curl. For example:
 
@@ -443,7 +443,7 @@ This command would return a response from the websocket server from the /socket
 
 Further, similar to gRPC testing, `linkerd stat` shall be used to check if there is constant traffic to and from the websocket endpoints.
 
-**3. MySQL and Redis**
+#### 3. MySQL and Redis
 
 - The emojivoto application shall be modified to have persistent storage. The `voting` deployment may be configured to work with MySQL and Redis (for cache). 
 - The `vote-bot` deployment may send constant traffic to `voting` which can be setup to simulate :