NO-JIRA - Hacking Guide Branch Name Updates

Updates the hacking guide docs to correct the branch names as "main"

docs/hacking-guide/en/code.md

@@ -99,18 +99,18 @@ related JIRA or an email to the [dev list](http://activemq.apache.org/mailing-li
 
          git push origin my_cool_feature  
 
-   Note that git push references the branch you are pushing and defaults to `master`, not your working branch.
+   Note that git push references the branch you are pushing and defaults to `main`, not your working branch.
 
 1. Discuss your planned changes (if you want feedback)
 
    On mailing list - http://activemq.apache.org/mailing-lists.html
    On IRC - irc://irc.freenode.org/apache-activemq or https://webchat.freenode.net/?channels=apache-activemq
 
-1. Once you're finished coding your feature/fix then rebase your branch against the latest master (applies your patches 
-   on top of master)
+1. Once you're finished coding your feature/fix then rebase your branch against the latest main (applies your patches 
+   on top of main)
 
          git fetch upstream  
-         git rebase -i upstream/master  
+         git rebase -i upstream/main  
          # if you have conflicts fix them and rerun rebase  
          # The -f, forces the push, alters history, see note below  
          git push -f origin my_cool_feature
@@ -128,13 +128,13 @@ related JIRA or an email to the [dev list](http://activemq.apache.org/mailing-li
     1. An email will automatically be sent to the ActiveMQ developer list.
     1. As part of the review you may see an automated test run comment on your request.
     1. After review a maintainer will merge your PR into the canonical git repository at which point those changes will 
-       be synced with the GitHub mirror repository (i.e. your `master`) and your PR will be closed by the `asfgit` bot.
+       be synced with the GitHub mirror repository (i.e. your `main`) and your PR will be closed by the `asfgit` bot.
 
 ## Other common tasks       
 
 1. Pulling updates from upstream
 
-        $ git pull --rebase upstream master
+        $ git pull --rebase upstream main
         
    (`--rebase` will automatically move your local commits, if any, on top of the latest branch you pull from; you can leave
    it off if you do not have any local commits).
@@ -154,7 +154,7 @@ related JIRA or an email to the [dev list](http://activemq.apache.org/mailing-li
         Writing objects: 100% (100/100), 10.67 KiB, done.  
         Total 100 (delta 47), reused 100 (delta 47)  
         To git@github.com:<your-user-name>/apache-artemis.git  
-           3382570..1fa25df  master -> master
+           3382570..1fa25df  main -> main
 
    You might need to say -f to force the changes.
 

docs/hacking-guide/en/history.md

@@ -26,6 +26,6 @@ Rebasing original donation
 
 It may be useful to look at the donation history combined with the artemis history. It is the case when eventually looking at old changes.
 
-For that there is a script that will rebase master against the donation branch under master/scripts:
+For that there is a script that will rebase main against the donation branch under main/scripts:
 
-- rebase-donation.sh
+- rebase-donation.sh

docs/hacking-guide/en/ide.md

@@ -2,7 +2,7 @@
 
 There a few files useful for IDE integration under ./etc/ide-settings on a checked out folder. This folder is not part of the source distribution, but it can be easily obtained:
 
-- https://github.com/apache/activemq-artemis/tree/master/etc/ide-settings
+- https://github.com/apache/activemq-artemis/tree/main/etc/ide-settings
 
 ## IntelliJ IDEA
 

docs/hacking-guide/en/maintainers.md

@@ -77,22 +77,22 @@ Here are the basic commands to retrieve pull requests, merge, and push them to t
 
         $ git checkout pr/105 -B 105
 
-1. Rebase the branch against master, so the merge would happen at the top of the current master
+1. Rebase the branch against main, so the merge would happen at the top of the current main
 
-        $ git pull --rebase apache master
+        $ git pull --rebase apache main
 
-1. Once you've reviewed the change and are ready to merge checkout `master`.
+1. Once you've reviewed the change and are ready to merge checkout `main`.
 
-        $ git checkout master
+        $ git checkout main
 
-1. Ensure you are up to date on your master also.
+1. Ensure you are up to date on your main also.
 
-        $ git pull --rebase apache master
+        $ git pull --rebase apache main
 
-1. We actually recommend checking out master again, to make sure you wouldn't add any extra commits by accident:
+1. We actually recommend checking out main again, to make sure you wouldn't add any extra commits by accident:
 
         $ git fetch apache
-        $ git checkout apache/master -B master
+        $ git checkout apache/main -B main
 
 1. Create a new merge commit from the pull-request. IMPORTANT: The commit message here should be something like: "This
    closes #105" where "105" is the pull request ID.  The "#105" shows up as a link in the GitHub UI for navigating to
@@ -103,7 +103,7 @@ Here are the basic commands to retrieve pull requests, merge, and push them to t
 
 1. Push to the canonical Apache repo.
 
-        $ git push apache master
+        $ git push apache main
 
 ## Using the automated script
 
@@ -129,38 +129,38 @@ The previous example was taken from a real case that generated this [merge commi
 
 - After this you can push to the canonical Apache repo.
 ```
-$ git push apache master
+$ git push apache main
 ```
 
 
 ## Use a separate branch for your changes
 
-It is recommended that you work away from master for two reasons:
+It is recommended that you work away from main for two reasons:
 
 1. When you send a PR, your PR branch could be rebased during the process and your commit ID changed. You might
    get unexpected conflicts while rebasing your old branch.
 
 1. You could end up pushing things upstream that you didn't intend to. Minimize your risks by working on a branch
-   away from master.
+   away from main.
 
 
 ## Notes:
 
 The GitHub mirror repository (i.e. `upstream`) is cloning the canonical Apache repository.  Because of this there may be
 a slight delay between when a commit is pushed to the Apache repo and when that commit is reflected in the GitHub mirror.
 This may cause some difficulty when trying to push a PR to `apache` that has been merged on the out-of-date GitHub mirror.
-You can wait for the mirror to update before performing the steps above or you can change your local master branch to
-track the master branch on the canonical Apache repository rather than the master branch on the GitHub mirror:
+You can wait for the mirror to update before performing the steps above or you can change your local main branch to
+track the main branch on the canonical Apache repository rather than the main branch on the GitHub mirror:
 
-    $ git branch master -u apache/master
+    $ git branch main -u apache/main
 
 Where `apache` points to the canonical Apache repository.
 
-If you'd like your local master branch to always track `upstream/master` (i.e. the GitHub mirror) then another way to
-achieve this is to add another branch that tracks `apache/master` and push from that branch e.g.
+If you'd like your local main branch to always track `upstream/main` (i.e. the GitHub mirror) then another way to
+achieve this is to add another branch that tracks `apache/main` and push from that branch e.g.
 
-    $ git checkout master
-    $ git branch apache_master --track apache/master
+    $ git checkout main
+    $ git branch apache_main --track apache/main
     $ git pull
     $ git merge --no-ff pr/105
     $ git push

docs/hacking-guide/en/tests.md

@@ -22,20 +22,20 @@ The broker is comprised of POJOs so it's simple to configure and run a broker in
 Even complex test-cases involving multiple clustered brokers are relatively easy to write. Almost every test in the 
 test-suite follows this pattern - configure broker, start broker, test functionality, stop broker.
 
-The test-suite uses JUnit to manage test execution and life-cycle.  Most tests extend [`org.apache.activemq.artemis.tests.util.ActiveMQTestBase`](https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/test/java/org/apache/activemq/artemis/tests/util/ActiveMQTestBase.java)
+The test-suite uses JUnit to manage test execution and life-cycle.  Most tests extend [`org.apache.activemq.artemis.tests.util.ActiveMQTestBase`](https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/test/java/org/apache/activemq/artemis/tests/util/ActiveMQTestBase.java)
 which contains JUnit setup and tear-down methods as well as a wealth of utility functions to configure, start, manage,
 and stop brokers as well as perform other common tasks.
 
-Check out [`org.apache.activemq.artemis.tests.integration.SimpleTest`](https://github.com/apache/activemq-artemis/blob/master/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/SimpleTest.java).
+Check out [`org.apache.activemq.artemis.tests.integration.SimpleTest`](https://github.com/apache/activemq-artemis/blob/main/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/SimpleTest.java).
 It's a very simple test-case that extends `org.apache.activemq.artemis.tests.util.ActiveMQTestBase` and uses its methods
 to configure a server, run a test, and then `super.tearDown()` cleans it up once the test completes. The test-case 
 includes comments to explain everything. As the name implies, this is a simple test-case that demonstrates the most basic
 functionality of the test-suite. A simple test like this takes less than a second to run on modern hardware.
 
 Although `org.apache.activemq.artemis.tests.integration.SimpleTest` is simple it could be simpler still by extending
-[`org.apache.activemq.artemis.tests.util.SingleServerTestBase`](https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/test/java/org/apache/activemq/artemis/tests/util/SingleServerTestBase.java).
+[`org.apache.activemq.artemis.tests.util.SingleServerTestBase`](https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/test/java/org/apache/activemq/artemis/tests/util/SingleServerTestBase.java).
 This class does all the setup of a simple server automatically and provides the test-case with a `ServerLocator`, 
-`ClientSessionFactory`, and `ClientSession` instance. [`org.apache.activemq.artemis.tests.integration.SingleServerSimpleTest`](https://github.com/apache/activemq-artemis/blob/master//tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/SingleServerSimpleTest.java)
+`ClientSessionFactory`, and `ClientSession` instance. [`org.apache.activemq.artemis.tests.integration.SingleServerSimpleTest`](https://github.com/apache/activemq-artemis/blob/main//tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/SingleServerSimpleTest.java)
 is an example based on `org.apache.activemq.artemis.tests.integration.SimpleTest` but extends `org.apache.activemq.artemis.tests.util.SingleServerTestBase`
 which eliminates all the setup and class variables which are provided by `SingleServerTestBase` itself.
 
@@ -81,7 +81,7 @@ As a general rule, only use System.out if you really intend an error to be on th
 An important task for any test-case is to clean up all the resources it creates when it runs. This includes the server
 instance itself and any resources created to connect to it (e.g. instances of `ServerLocator`, `ClientSessionFactory`,
 `ClientSession`, etc.). This task is typically completed in the test's `tearDown()` method.  However, `ActiveMQTestBase` 
-(and other classes which extend it) simplifies this process. As [`org.apache.activemq.artemis.tests.integration.SimpleTest`](https://github.com/apache/activemq-artemis/blob/master/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/SimpleTest.java)
+(and other classes which extend it) simplifies this process. As [`org.apache.activemq.artemis.tests.integration.SimpleTest`](https://github.com/apache/activemq-artemis/blob/main/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/SimpleTest.java)
 demonstrates, there are several methods you can use when creating your test which will ensure proper clean up _automatically_
 when the test is torn down. These include: