Missing content for testProxy.md , spellchecked stress, added /doc as triggetr for the core pipeline (#4296)

* docs for stress perf

* dotnet contrib

* missing content plus pipeline trigger

* stress tests spell checked

* one more

doc/StressTest.md

@@ -1,6 +1,6 @@
 # Stress Test
 
-## Deps
+## Dependencies
 Adding a stress test requires the following tools installed:
 * Docker : https://www.docker.com/
 * Helm : https://helm.sh/
@@ -9,12 +9,12 @@ Adding a stress test requires the following tools installed:
 Structure : 
 
 A stress tests is composes of the following components : 
-* Source code : represents the test that is run, there are no prerequisites as to what the code does, the outputs of the tests can be at the cosole , as file share or Application Insights. 
-* DockerFile : represents the docker file that will build the continer image that  will be executed by the stress automation, on the stress test clusters. 
+* Source code : represents the test that is run, there are no prerequisites as to what the code does, the outputs of the tests can be at the console , as file share or Application Insights. 
+* DockerFile : represents the docker file that will build the container image that  will be executed by the stress automation, on the stress test clusters. 
 * Helm Chart : represents the deployment script for the docker image built by the Dockerfile. 
 * stress-test-resources.bicep/json ARM template for deploying azure resources required by the 
 tests 
-* scenarios-matrix.yaml : definition of tests and which are offered in one docker image. e.g. We can have multiple tests coexisting in a single docer image, the definition conmtains a list of test names and executables (with params) that will be executed in order to run those tests.
+* scenarios-matrix.yaml : definition of tests and which are offered in one docker image. e.g. We can have multiple tests coexisting in a single docker image, the definition contains a list of test names and executables (with params) that will be executed in order to run those tests.
 
 To deploy a stress test to the playground (test) clusters, you will need to execute the following script : "eng/common/scripts/stress-testing/deploy-stress-tests.ps1 -Login -PushImages" in the folder of where the dockerfile exists. 
 
@@ -24,6 +24,6 @@ The deployment script will run the following steps :
 * deploy the arm resources
 * build the docker image 
 * read the scenarios and generate the final helm chart 
-* deploy the helm chart - caveat - make sure to have a .helmignore file present in which you exclude files that are not required for the deployment (e.g. test source code) . When initiating a deplyment helm zips the whole folder , in order to upload it the chart needs to be less than 1MB. Thus excluding any uneeded files is advisable. 
+* deploy the helm chart - caveat - make sure to have a .helmignore file present in which you exclude files that are not required for the deployment (e.g. test source code) . When initiating a deployment helm zips the whole folder , in order to upload it the chart needs to be less than 1MB. Thus excluding any unneeded files is advisable. 
 
 The Dockerfile is very flexible, it can be used to include the binaries for the tests or include the code and run the config/build of the tests as part of the build , or anything in between. The only requirement is that the command lines to run the test executables are specified in the scenarios.txt

doc/TestProxy.md

@@ -0,0 +1,55 @@
+# Test Proxy
+
+As the name implies is a proxy for http(s) requests performed by tests. While requests are proxied it allows for the recording and playback of the responses matching the requests. this way we can have a deterministic set og http request/responses allowing for predictable tests. 
+
+## Recordings
+
+The recordings are stored long term in a separate git repo indicated in the assets.json files peppered throughout the repo. 
+E.G.:
+```JSON
+{
+  "AssetsRepo": "Azure/azure-sdk-assets",
+  "AssetsRepoPrefixPath": "cpp",
+  "TagPrefix": "cpp/keyvault",
+  "Tag": "cpp/keyvault_ea82152bd3"
+}
+```
+The recordings are kept as releases for the repo with the tag indicated in the json file.
+
+## Install test-proxy
+
+```BASH
+dotnet tool update azure.sdk.tools.testproxy --global --add-source https://pkgs.dev.azure.com/azure-sdk/public/_packaging/azure-sdk-for-net/nuget/v3/index.json --version "1.0.0-dev*"
+```
+
+Will install the latest version of the test-proxy using the dotnet tool.
+
+## Starting test-proxy
+
+When starting the test proxy you have several options :
+
+* in the folder where assets.json exists run "test-proxy". in this case the proxy will read the local assets file and will download the indicated recording set when the first test is  executed. 
+* by running test-proxy from any location and passing in the path to the assets.json file as a parameter to the executable. (test-proxy --help)
+* as a docker image (https://github.com/Azure/azure-sdk-tools/tree/main/tools/test-proxy/docker)
+
+## Creating a recording 
+When AZURE_TEST_MODE=RECORD we will  first call the test-proxy /record/start endpoint with a json payload indicating we are starting a test run, when the test is done we call recording/stop with the recording id previously returned when starting. 
+
+The proxy will create a file locally containing the data in the .assets folder in the root of the enlistment. 
+
+## Playback 
+
+When AZURE_TEST_MODE=PLAYBACK we invoke the playback/start endpoint on test-proxy which causes it to download the appropriate release indicated in assets.json if it is not there already, and replay the responses for the specific request based on the recorded data. When the test is done we call playback/stop
+
+## LIve Testing
+
+When AZURE_TEST_MODE=LIVE all requests are sent directly to their destination bypassing the proxy.
+
+## Updating the remote
+
+When all recordings are done, we can call "test-proxy push" which will cause the proxy to push the changes to the remote, create a new release with the appropriate tags and generate the assets.json file. 
+
+## Advanced
+
+The test-proxy will fetch the assets lazily, thus the first test execution will take a long time depending on external factors such as network, disk speed, cpu etc. While this is a one time event it can cause timeouts especially in environments that are time bound(e.g. piplines). 
+To solve this issue we can run test-proxy -restore, which will force the download of the data. 

sdk/core/ci.yml

@@ -14,6 +14,7 @@ trigger:
       - eng/
       - CMakeLists.txt
       - sdk/core
+      - doc/
 
 pr:
   branches:
@@ -29,6 +30,7 @@ pr:
       - eng/
       - CMakeLists.txt
       - sdk/core
+      - doc/
 
 stages:
   - template: ../../eng/pipelines/templates/stages/archetype-sdk-client.yml