Update references to master branch in developer documentation

BUILDING.md

@@ -70,7 +70,7 @@ Elasticsearch specific build logic is located in the `build-tools-internal` subp
 
 - Gradle plugins and Tasks should be written in Java
 - We use a groovy and spock for setting up Gradle integration tests.
-  (see https://github.com/elastic/elasticsearch/blob/master/build-tools/src/testFixtures/groovy/org/elasticsearch/gradle/fixtures/AbstractGradleFuncTest.groovy)
+  (see https://github.com/elastic/elasticsearch/blob/main/build-tools/src/testFixtures/groovy/org/elasticsearch/gradle/fixtures/AbstractGradleFuncTest.groovy)
 
 #### Declaring tasks
 
@@ -95,7 +95,7 @@ Therefore we register test cluster by using the following syntax:
 
     def someClusterProvider = testClusters.register('someCluster') { ... }
 
-This registers a potential testCluster named `somecluster` and provides a provider instance, but doesn't create it yet nor configures it. This makes the gradle configuration phase more efficient by 
+This registers a potential testCluster named `somecluster` and provides a provider instance, but doesn't create it yet nor configures it. This makes the gradle configuration phase more efficient by
 doing less.
 
 To wire this registered cluster into a `TestClusterAware` task (e.g. `RestIntegTest`) you can resolve the actual cluster from the provider instance:
@@ -170,9 +170,9 @@ To test an unreleased development version of a third party dependency you have s
 
 #### How to use a maven built based third party dependency with jitpack repository?
 
-https://jitpack.io is an adhoc repository that supports building maven projects transparently in the background when 
+https://jitpack.io is an adhoc repository that supports building maven projects transparently in the background when
 resolving unreleased snapshots from a github repository. This approach also works as temporally solution
-and is compliant with our CI builds. 
+and is compliant with our CI builds.
 
 1. Add the JitPack repository to the root build file:
 
@@ -190,11 +190,11 @@ dependencies {
 }
 ```
 
-As version you could also use a certain short commit hash or `master-SNAPSHOT`.
+As version you could also use a certain short commit hash or `main-SNAPSHOT`.
 In addition to snapshot builds JitPack supports building Pull Requests. Simply use PR<NR>-SNAPSHOT as the version.
 
-3. Run the gradle build as needed. Keep in mind the initial resolution might take a bit longer as this needs to be built 
-by JitPack in the background before we can resolve the adhoc built dependency. 
+3. Run the gradle build as needed. Keep in mind the initial resolution might take a bit longer as this needs to be built
+by JitPack in the background before we can resolve the adhoc built dependency.
 
 ---
 
@@ -213,7 +213,7 @@ a flat directory repository that resolves artifacts from a flat directory on you
 2. Declare a flatDir repository in your root build.gradle file
 
 ```
-allprojects { 
+allprojects {
   repositories {
       flatDir {
           dirs 'localRepo'
@@ -222,9 +222,9 @@ allprojects {
 }
 ```
 
-3. Update the dependency declaration of the artifact in question to match the custom build version. For a file named e.g. `jmxri-1.2.1.jar` the 
+3. Update the dependency declaration of the artifact in question to match the custom build version. For a file named e.g. `jmxri-1.2.1.jar` the
   dependency definition would be `:jmxri:1.2.1` as it comes with no group information:
-  
+
   ```
   dependencies {
       implementation ':jmxri:1.2.1'

CONTRIBUTING.md

@@ -87,7 +87,7 @@ Once your changes and tests are ready to submit for review:
 
 3. Rebase your changes
 
-    Update your local repository with the most recent code from the main Elasticsearch repository, and rebase your branch on top of the latest master branch. We prefer your initial changes to be squashed into a single commit. Later, if we ask you to make changes, add them as separate commits.  This makes them easier to review.  As a final step before merging we will either ask you to squash all commits yourself or we'll do it for you.
+    Update your local repository with the most recent code from the main Elasticsearch repository, and rebase your branch on top of the latest main branch. We prefer your initial changes to be squashed into a single commit. Later, if we ask you to make changes, add them as separate commits.  This makes them easier to review.  As a final step before merging we will either ask you to squash all commits yourself or we'll do it for you.
 
 
 4. Submit a pull request
@@ -100,8 +100,8 @@ Please adhere to the general guideline that you should never force push
 to a publicly shared branch. Once you have opened your pull request, you
 should consider your branch publicly shared. Instead of force pushing
 you can just add incremental commits; this is generally easier on your
-reviewers. If you need to pick up changes from master, you can merge
-master into your branch. A reviewer might ask you to rebase a
+reviewers. If you need to pick up changes from main, you can merge
+main into your branch. A reviewer might ask you to rebase a
 long-running pull request in which case force pushing is okay for that
 request. Note that squashing at the end of the review process should
 also not be done, that can be done when the pull request is [integrated
@@ -266,7 +266,7 @@ IntelliJ IDEs can
 the same settings file, and / or use the [Eclipse Code Formatter] plugin.
 
 You can also tell Spotless to [format a specific
-file](https://github.com/diffplug/spotless/tree/master/plugin-gradle#can-i-apply-spotless-to-specific-files)
+file](https://github.com/diffplug/spotless/tree/main/plugin-gradle#can-i-apply-spotless-to-specific-files)
 from the command line.
 
 ### Javadoc
@@ -696,7 +696,7 @@ If your changes affect only the documentation, run:
     ./gradlew -p docs check
 
 For more information about testing code examples in the documentation, see
-https://github.com/elastic/elasticsearch/blob/master/docs/README.asciidoc
+https://github.com/elastic/elasticsearch/blob/main/docs/README.asciidoc
 
 ### Only running failed tests
 
@@ -931,4 +931,4 @@ repeating in this section because it has come up in this context.
 [Checkstyle]: https://plugins.jetbrains.com/plugin/1065-checkstyle-idea
 [spotless]: https://github.com/diffplug/spotless
 [Eclipse Code Formatter]: https://plugins.jetbrains.com/plugin/6546-eclipse-code-formatter
-[Spotless Gradle]: https://github.com/diffplug/spotless/tree/master/plugin-gradle
+[Spotless Gradle]: https://github.com/diffplug/spotless/tree/main/plugin-gradle

REST_API_COMPATIBILITY.md

@@ -99,7 +99,7 @@ PARSER.declareInt(MyPojo::setMax, new ParseField("maximum").forRestApiVersion(Re
 
 The above example is for code that live in the version 8 branch of code. In this example, `limit` has been deprecated in version 7 and removed in version 8.  The above code reads use the `maximum` value from the request for both version 7 and version 8. However, if compatibility is requested it will also allow `limit` in the payload.  If `limit` is used a warning will be emitted.
 
-The version in `forRestApiVersion` is reference to when the declaration is valid. Assuming version 8 is the master branch and all changes start in the master branch then get back ported. The above text is what would be applicable for the v8 branch of code. The first line of code is essentially ignored except for when compatibility with version 7 is requested. When back-porting this change to the 7.x branch, the first line would be identical, and the second line would be omitted.
+The version in `forRestApiVersion` is reference to when the declaration is valid. Assuming version 8 is the main branch and all changes start in the main branch then get back ported. The above text is what would be applicable for the v8 branch of code. The first line of code is essentially ignored except for when compatibility with version 7 is requested. When back-porting this change to the 7.x branch, the first line would be identical, and the second line would be omitted.
 
 The above strategy works well for single fields, but could get overly complex very fast for large multiple field changes. For more complex de-serialization changes there is also support to construct a `NamedXContentRegistry` with some "normal" entries as well some entries that are only applied when compatibility with the prior version is requested. The syntax is very similar where can express the desired version from the required `ParseField` when adding an entry to the `NamedXContentRegistry`.
 
@@ -172,7 +172,7 @@ In some cases the prior version of the YAML REST tests are not sufficient to ful
 
 ### Developer's workflow
 
-There should not be much, if any, deviation in a developers normal workflow to introduce and back-port changes. Changes should be applied in master, then back ported as needed.
+There should not be much, if any, deviation in a developers normal workflow to introduce and back-port changes. Changes should be applied in main, then back ported as needed.
 
 Most of the compatibility will work correctly when back-porting as-is, but some care is needed that the logic is correct for that version when back-porting.  For example, both the route (URL) and field (de-serialization) declarations with version awareness will behave differently if the declared version is the current version or the prior version. This allows the same line of code to be back ported as-is with differing behavior.  Additionally the compatible version is always populated (even when not requested, defaulting to the current version), so conditional logic comparing against a specific version is safe across branches.
 
@@ -180,7 +180,7 @@ Mixed clusters are not explicitly tested since the change should be applied at t
 
 ### Troubleshooting compatibility test failures
 
-By far the most common reason that compatibility tests can seemingly randomly fail is that your master branch is out of date with the upstream master. For this reason, it always suggested to ensure that your PR branch is up to date.
+By far the most common reason that compatibility tests can seemingly randomly fail is that your main branch is out of date with the upstream main. For this reason, it always suggested to ensure that your PR branch is up to date.
 
 Test failure reproduction lines should behave identical to the non-compatible variant. However, to assure you are referencing the correct line number when reading the test, be sure to look at the line number from the transformed test on disk.  Generally the fully transformed tests can be found at `build/restResources/v7/yamlTests/transformed/rest-api-spec/test/*` (where v7 will change with different versions).
 

TESTING.asciidoc

@@ -623,7 +623,7 @@ sure that a branch is available and is up to date in the case of multiple runs.
 
 Example:
 
-Say you need to make a change to `master` and have a BWC layer in `5.x`. You
+Say you need to make a change to `main` and have a BWC layer in `5.x`. You
 will need to:
 . Create a branch called `index_req_change` off your remote `${remote}`. This
 will contain your change.