Updated master branch references to main (#256)

* Updated master branch references to main.

* Update LICENSE.txt for branch name change

Author: trmartin4

LICENSE.txt

@@ -2,11 +2,11 @@ Source code in this repository is covered by one of two licenses: (i) the GNU Ge
 (GPL) v3.0 (ii) the Creative Commons BY-NC-ND v4.0. Creative Commons licensed documents are found in
 the docs directory. Other files are GPL licensed.
 
-GPL v3.0: https://github.com/bitwarden/contributing-docs/blob/master/LICENSE_GPL.txt
+GPL v3.0: https://github.com/bitwarden/contributing-docs/blob/main/LICENSE_GPL.txt
 
-CC BY-NC-ND v4.0: https://github.com/bitwarden/contributing-docs/blob/master/LICENSE_CC.txt
+CC BY-NC-ND v4.0: https://github.com/bitwarden/contributing-docs/blob/main/LICENSE_CC.txt
 
 No grant of any rights in the trademarks, service marks, or logos of Bitwarden is made (except as
 may be necessary to comply with the notice requirements as applicable), and use of any Bitwarden
 trademarks must comply with Bitwarden Trademark Guidelines
-<https://github.com/bitwarden/server/blob/master/TRADEMARK_GUIDELINES.md>.
+<https://github.com/bitwarden/server/blob/main/TRADEMARK_GUIDELINES.md>.

docs/architecture/adr/0019-adopt-web-push.md

@@ -120,7 +120,7 @@ be considered while migrating compatible clients to the new provider to provide
 potentially-sensitive payload contents.
 
 [signalr]: https://dotnet.microsoft.com/en-us/apps/aspnet/signalr
-[notifications]: https://github.com/bitwarden/server/tree/master/src/Notifications
+[notifications]: https://github.com/bitwarden/server/tree/main/src/Notifications
 [podlife]: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/
 [mv3]: https://developer.chrome.com/docs/extensions/mv3/intro/
 [hubspricing]: https://azure.microsoft.com/en-us/pricing/details/notification-hubs/

docs/architecture/deep-dives/authentication/index.md

@@ -17,14 +17,14 @@ factors, but the most important is the login strategy.
 ## Client requests a token
 
 For each of these strategies, the client forms a
-[`TokenRequest`](https://github.com/bitwarden/clients/blob/master/libs/common/src/auth/models/request/identity-token/token.request.ts)
+[`TokenRequest`](https://github.com/bitwarden/clients/blob/main/libs/common/src/auth/models/request/identity-token/token.request.ts)
 though one of its subclasses:
 
-- [`PasswordTokenRequest`](https://github.com/bitwarden/clients/blob/master/libs/common/src/auth/models/request/identity-token/password-token.request.ts) -
+- [`PasswordTokenRequest`](https://github.com/bitwarden/clients/blob/main/libs/common/src/auth/models/request/identity-token/password-token.request.ts) -
   used by Password and Passwordless Login Strategy
-- [`UserApiTokenRequest`](https://github.com/bitwarden/clients/blob/master/libs/common/src/auth/models/request/identity-token/user-api-token.request.ts) -
+- [`UserApiTokenRequest`](https://github.com/bitwarden/clients/blob/main/libs/common/src/auth/models/request/identity-token/user-api-token.request.ts) -
   used by API Login Strategy
-- [`SSOTokenRequest`](https://github.com/bitwarden/clients/blob/master/libs/common/src/auth/models/request/identity-token/user-api-token.request.ts) -
+- [`SSOTokenRequest`](https://github.com/bitwarden/clients/blob/main/libs/common/src/auth/models/request/identity-token/user-api-token.request.ts) -
   used by SSO Login Strategy
 
 Each of these requests overrides the `toIdentityToken()` method, which is responsible for
@@ -39,8 +39,8 @@ strategies.
 <!-- prettier-ignore -->
 | Property | Purpose |
 | --- | --- |
-| `deviceType` | The [`DeviceType`](https://github.com/bitwarden/clients/blob/master/libs/common/src/enums/device-type.enum.ts) for the requesting device. |
-| `deviceName` | The string representation of the [`DeviceType`](https://github.com/bitwarden/clients/blob/master/libs/common/src/enums/device-type.enum.ts) for the requesting device. |
+| `deviceType` | The [`DeviceType`](https://github.com/bitwarden/clients/blob/main/libs/common/src/enums/device-type.enum.ts) for the requesting device. |
+| `deviceName` | The string representation of the [`DeviceType`](https://github.com/bitwarden/clients/blob/main/libs/common/src/enums/device-type.enum.ts) for the requesting device. |
 | `deviceIdentifier` | The unique identifier for the device, generated on the device when the application is installed. 
 | `twoFactorToken` | For users who have two-factor authentication enabled, contains the token generated by the 2FA provider. Empty otherwise. See [Two-Factor Authentication](./two-factor-auth.md) for details. |
 | `twoFactorTokenProvider` | The 2FA provider that generated the token in `twoFactorToken`. Empty otherwise. |
@@ -138,7 +138,7 @@ There are different types of clients that can request access with the client_cre
 
 The different API client types all have different validation. The key to `client_credentials` grant
 type validation is the `ClientStore` that is built in to IdentityServer (and
-[overridden](https://github.com/bitwarden/server/blob/master/src/Identity/IdentityServer/ClientStore.cs)
+[overridden](https://github.com/bitwarden/server/blob/main/src/Identity/IdentityServer/ClientStore.cs)
 in our code). The `ClientStore` is queried on each request in the .NET request middleware pipeline
 to find the client for a given `client_id` from the request.
 
@@ -244,7 +244,7 @@ decrypted.
 
 The core logic for handling the token responses is in the `processTokenResponse()` method in our
 base
-[`LoginStrategy`](https://github.com/bitwarden/clients/blob/master/libs/common/src/auth/login-strategies/login.strategy.ts)
+[`LoginStrategy`](https://github.com/bitwarden/clients/blob/main/libs/common/src/auth/login-strategies/login.strategy.ts)
 where we do the following:
 
 ### Use the Authentication information to set up the user’s account

docs/architecture/deep-dives/authentication/two-factor-auth.md

@@ -27,13 +27,13 @@ JSON data:
 ## Handling 2FA response on the client
 
 If the client detects a
-[`IdentityTwoFactorResponse`](https://github.com/bitwarden/clients/blob/master/libs/common/src/auth/models/response/identity-two-factor.response.ts)
+[`IdentityTwoFactorResponse`](https://github.com/bitwarden/clients/blob/main/libs/common/src/auth/models/response/identity-two-factor.response.ts)
 when attempting to log in, it extracts the available 2FA providers from the `CustomResponse` and
 presents those to the user.
 
 Each 2FA method has its own UI, but in all cases the user will generate a "token" of some sort to
 capture the user's response. This token is captured on the
-[`TwoFactorComponent`](https://github.com/bitwarden/clients/blob/master/apps/desktop/src/auth/two-factor.component.ts)
+[`TwoFactorComponent`](https://github.com/bitwarden/clients/blob/main/apps/desktop/src/auth/two-factor.component.ts)
 when the user completes the 2FA process.
 
 Once the user has entered their 2FA, a new authentication request is `POST`ed to the

docs/architecture/deep-dives/autofill/collecting-page-details.md

@@ -15,7 +15,7 @@ by a content script. The Bitwarden browser extension performs this in the `colle
 :::info Page Details
 
 For in-depth knowledge of what is contained in the Page Details, the
-[`AutofillPageDetails`](https://github.com/bitwarden/clients/blob/master/apps/browser/src/autofill/models/autofill-page-details.ts)
+[`AutofillPageDetails`](https://github.com/bitwarden/clients/blob/main/apps/browser/src/autofill/models/autofill-page-details.ts)
 TypeScript class is documented to explain the properties and their purposes.
 
 :::
@@ -249,13 +249,13 @@ details. When this occurs, the collection of the page details takes place throug
 method in the script.
 
 The `collect()` method parses the page DOM and creates an instance of the
-[`AutofillPageDetails`](https://github.com/bitwarden/clients/blob/master/apps/browser/src/autofill/models/autofill-page-details.ts)
+[`AutofillPageDetails`](https://github.com/bitwarden/clients/blob/main/apps/browser/src/autofill/models/autofill-page-details.ts)
 class.
 
 This class contains arrays of
-[`AutofillField`](https://github.com/bitwarden/clients/blob/master/apps/browser/src/autofill/models/autofill-field.ts)
+[`AutofillField`](https://github.com/bitwarden/clients/blob/main/apps/browser/src/autofill/models/autofill-field.ts)
 and
-[`AutofillForm`](https://github.com/bitwarden/clients/blob/master/apps/browser/src/autofill/models/autofill-form.ts)
+[`AutofillForm`](https://github.com/bitwarden/clients/blob/main/apps/browser/src/autofill/models/autofill-form.ts)
 objects, each of which represents a potentially fillable field on the page source. The properties on
 the objects are used in the next step of the Autofill process,
 ['Generating the Fill Scripts'](./generating-fill-scripts.md).

docs/architecture/deep-dives/autofill/generating-fill-scripts.md

@@ -14,7 +14,7 @@ instructions that tell the `autofill.js` content script what fields to fill and
 should fill each field.
 
 The generation of fill scripts is the responsibility of the
-[`AutofillService`](https://github.com/bitwarden/clients/blob/master/apps/browser/src/autofill/services/autofill.service.ts).
+[`AutofillService`](https://github.com/bitwarden/clients/blob/main/apps/browser/src/autofill/services/autofill.service.ts).
 There are three method used to perform fill script generation:
 
 - `doAutoFill()`
@@ -98,7 +98,7 @@ done by looking at all fields in the Page Details **prior** to the password in t
 either:
 
 - An exact match from the
-  [`UsernameFieldNames`](https://github.com/bitwarden/clients/blob/master/apps/browser/src/autofill/services/autofill-constants.ts)
+  [`UsernameFieldNames`](https://github.com/bitwarden/clients/blob/main/apps/browser/src/autofill/services/autofill-constants.ts)
   list, or
 - The text, email, or telephone field closest to the password field in the DOM
 
@@ -148,7 +148,7 @@ For that field, we then loop through all of the field's attributes from the `Car
 - `data-recurly`
 
 In the
-[`CreditCardAutoFillConstants`](https://github.com/bitwarden/clients/blob/master/apps/browser/src/autofill/services/autofill-constants.ts),
+[`CreditCardAutoFillConstants`](https://github.com/bitwarden/clients/blob/main/apps/browser/src/autofill/services/autofill-constants.ts),
 we define a static list of possible matching values for each of the fields on the Card Cipher type.
 For example, we define a `CardHolderFieldNames` array, which has all of the attribute values that we
 look for to find the likely "Cardholder Name" field in the DOM - and thus the field we want to fill
@@ -196,7 +196,7 @@ array. For that field, we then loop through all of the field's attributes from t
 - `data-recurly`
 
 In the
-[`IdentityAutoFillConstants`](https://github.com/bitwarden/clients/blob/master/apps/browser/src/autofill/services/autofill-constants.ts),
+[`IdentityAutoFillConstants`](https://github.com/bitwarden/clients/blob/main/apps/browser/src/autofill/services/autofill-constants.ts),
 we define a static list of possible matching values for each of the fields on the Identity Cipher
 type. For example, we define a `FirstnameFieldNames` array, which has all of the attribute values
 that we look for to find the likely "First Name" field in the DOM - and thus the field we want to

docs/architecture/deep-dives/event-logs/index.md

@@ -21,11 +21,11 @@ cannot be circumvented by modifying the client.
 ## Writing Events
 
 Events are handled on our clients through the
-[`EventCollectionService`](https://github.com/bitwarden/clients/blob/master/libs/common/src/services/event/event-collection.service.ts)
+[`EventCollectionService`](https://github.com/bitwarden/clients/blob/main/libs/common/src/services/event/event-collection.service.ts)
 and
-[`EventUploadService`](https://github.com/bitwarden/clients/blob/master/libs/common/src/services/event/event-upload.service.ts)
+[`EventUploadService`](https://github.com/bitwarden/clients/blob/main/libs/common/src/services/event/event-upload.service.ts)
 for our JavaScript clients and the
-[`EventService`](https://github.com/bitwarden/mobile/blob/master/src/Core/Services/EventService.cs)
+[`EventService`](https://github.com/bitwarden/mobile/blob/main/src/Core/Services/EventService.cs)
 for our mobile clients. These services enqueue the events into a collection stored client-side which
 is periodically uploaded to the server, currently at 60 seconds intervals. Logs are also uploaded on
 logout, so there are no events orphaned in the collection.
@@ -42,42 +42,42 @@ by the `IEventWriteService`.
 ### Cloud-Hosted
 
 For cloud-hosted instances, we use the
-[`AzureQueueEventWriteService`](https://github.com/bitwarden/server/blob/master/src/Core/Services/Implementations/AzureQueueEventWriteService.cs)
+[`AzureQueueEventWriteService`](https://github.com/bitwarden/server/blob/main/src/Core/Services/Implementations/AzureQueueEventWriteService.cs)
 implementation, which writes the events to an Azure Queue that is specified in the
 `globalSettings.Events.ConnectionString` configuration setting.
 
 The events in the Azure Queue are then processed by the `EventsProcessor` service that runs in the
 Bitwarden cloud-hosted instance. The `EventsProcessor` is running the
-[`AzureQueueHostedService`](https://github.com/bitwarden/server/blob/master/src/EventsProcessor/AzureQueueHostedService.cs),
+[`AzureQueueHostedService`](https://github.com/bitwarden/server/blob/main/src/EventsProcessor/AzureQueueHostedService.cs),
 which dequeues the event logs from the Azure Queue and writes them to Azure Table storage using the
-[`EventRepository`](https://github.com/bitwarden/server/blob/master/src/Core/Repositories/TableStorage/EventRepository.cs).
+[`EventRepository`](https://github.com/bitwarden/server/blob/main/src/Core/Repositories/TableStorage/EventRepository.cs).
 
 ### Self-Hosted
 
 On self-hosted instances, the
-[`RepositoryEventWriteService`](https://github.com/bitwarden/server/blob/master/src/Core/Services/Implementations/RepositoryEventWriteService.cs)
+[`RepositoryEventWriteService`](https://github.com/bitwarden/server/blob/main/src/Core/Services/Implementations/RepositoryEventWriteService.cs)
 writes the event logs to the `Events` database table directly using the `EventRepository`.
 
 ## Querying Events
 
 Event logs are queried through the
-[`EventsController`](https://github.com/bitwarden/server/blob/master/src/Api/Public/Controllers/EventsController.cs)
+[`EventsController`](https://github.com/bitwarden/server/blob/main/src/Api/Public/Controllers/EventsController.cs)
 on the Bitwarden API.
 
 As with writing events, the querying of events differs based on the hosting method used for your
 Bitwarden instance. Since the events are logged to different places (Azure Table storage vs. the
 Bitwarden SQL database), the querying of these events must be different as well.
 
 We do this with Dependency Injection in the `Api` project. The
-[`IEventRepository`](https://github.com/bitwarden/server/blob/master/src/Core/Repositories/IEventRepository.cs)
+[`IEventRepository`](https://github.com/bitwarden/server/blob/main/src/Core/Repositories/IEventRepository.cs)
 will have different implementations based on the hosting environment and the database provider in
 use.
 
 ### Cloud-Hosted
 
 For cloud-hosted Bitwarden instances, the `EventsController` will query the Azure Table storage to
 look for the event logs, through the
-[`Bit.Core.Repositories.TableStorage.EventRepository`](https://github.com/bitwarden/server/blob/master/src/Core/Repositories/TableStorage/EventRepository.cs)
+[`Bit.Core.Repositories.TableStorage.EventRepository`](https://github.com/bitwarden/server/blob/main/src/Core/Repositories/TableStorage/EventRepository.cs)
 class, which implements `IEventRepository`.
 
 ### Self-Hosted