Merging to release-5.3: [DX-1508, DX-1511] Update config.go godoc com…

…ments with American spelling conversions (#6436)

[DX-1508, DX-1511] Update config.go godoc comments with American spelling conversions (#6436)

<!-- Provide a general summary of your changes in the Title above -->

## Description

[DX-1508](https://tyktech.atlassian.net/browse/DX-1508) involves
updating config.go godoc comments with American spelling conversions. If
merged could include as part of 5.3.3/5.5 release

## Related Issue

<!-- This project only accepts pull requests related to open issues. -->
<!-- If suggesting a new feature or change, please discuss it in an
issue first. -->
<!-- If fixing a bug, there should be an issue describing it with steps
to reproduce. -->
<!-- OSS: Please link to the issue here. Tyk: please create/link the
JIRA ticket. -->

## Motivation and Context

<!-- Why is this change required? What problem does it solve? -->

## How This Has Been Tested

<!-- Please describe in detail how you tested your changes -->
<!-- Include details of your testing environment, and the tests -->
<!-- you ran to see how your change affects other areas of the code,
etc. -->
<!-- This information is helpful for reviewers and QA. -->

## Screenshots (if appropriate)

## Types of changes

<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->

- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Refactoring or add test (improvements in base code or adds test
coverage to functionality)

## Checklist

<!-- Go over all the following points, and put an `x` in all the boxes
that apply -->
<!-- If there are no documentation updates required, mark the item as
checked. -->
<!-- Raise up any additional concerns not covered by the checklist. -->

- [x] I ensured that the documentation is up to date
- [ ] I explained why this PR updates go.mod in detail with reasoning
why it's required
- [ ] I would like a code coverage CI quality gate exception and have
explained why


[DX-1508]:
https://tyktech.atlassian.net/browse/DX-1508?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

---------

Co-authored-by: Simon Pears <[email protected]>

config/config.go

@@ -207,7 +207,7 @@ type AnalyticsConfigConfig struct {
 
 	// Set this value to `true` to have Tyk store the inbound request and outbound response data in HTTP Wire format as part of the Analytics data.
 	// Please note, this will greatly increase your analytics DB size and can cause performance degradation on analytics processing by the Dashboard.
-	// This setting can be overridden with an organisation flag, enabed at an API level, or on individual Key level.
+	// This setting can be overridden with an organization flag, enabed at an API level, or on individual Key level.
 	EnableDetailedRecording bool `json:"enable_detailed_recording"`
 
 	// Tyk can store GeoIP information based on MaxMind DB’s to enable GeoIP tracking on inbound request analytics. Set this value to `true` and assign a DB using the `geo_ip_db_path` setting.
@@ -286,7 +286,7 @@ type MonitorConfig struct {
 	GlobalTriggerLimit float64 `json:"global_trigger_limit"`
 	// Apply the monitoring subsystem to user keys.
 	MonitorUserKeys bool `json:"monitor_user_keys"`
-	// Apply the monitoring subsystem to organisation keys.
+	// Apply the monitoring subsystem to organization keys.
 	MonitorOrgKeys bool `json:"monitor_org_keys"`
 }
 
@@ -317,7 +317,7 @@ type SlaveOptionsConfig struct {
 	// Use this setting to add the URL for your MDCB or load balancer host.
 	ConnectionString string `json:"connection_string"`
 
-	// Your organisation ID to connect to the MDCB installation.
+	// Your organization ID to connect to the MDCB installation.
 	RPCKey string `json:"rpc_key"`
 
 	// This the API key of a user used to authenticate and authorise the Gateway’s access through MDCB.
@@ -334,8 +334,8 @@ type SlaveOptionsConfig struct {
 	// Set this option to `true` if you don’t want to monitor changes in the keys from a primary Gateway.
 	DisableKeySpaceSync bool `json:"disable_keyspace_sync"`
 
-	// This is the `zone` that this instance inhabits, e.g. the cluster/data-centre the Gateway lives in.
-	// The group ID must be the same across all the Gateways of a data-centre/cluster which are also sharing the same Redis instance.
+	// This is the `zone` that this instance inhabits, e.g. the cluster/data-center the Gateway lives in.
+	// The group ID must be the same across all the Gateways of a data-center/cluster which are also sharing the same Redis instance.
 	// This ID should also be unique per cluster (otherwise another Gateway cluster can pick up your keyspace events and your cluster will get zero updates).
 	GroupID string `json:"group_id"`
 
@@ -718,7 +718,7 @@ type Config struct {
 
 	// Disable the capability of the Gateway to `autodiscover` the Dashboard through heartbeat messages via Redis.
 	// The goal of zeroconf is auto-discovery, so you do not have to specify the Tyk Dashboard address in your Gateway`tyk.conf` file.
-	// In some specific cases, for example, when the Dashboard is bound to a public domain, not accessible inside an internal network, or similar, `disable_dashboard_zeroconf` can be set to `true`, in favour of directly specifying a Tyk Dashboard address.
+	// In some specific cases, for example, when the Dashboard is bound to a public domain, not accessible inside an internal network, or similar, `disable_dashboard_zeroconf` can be set to `true`, in favor of directly specifying a Tyk Dashboard address.
 	DisableDashboardZeroConf bool `json:"disable_dashboard_zeroconf"`
 
 	// The `slave_options` allow you to configure the RPC slave connection required for MDCB installations.
@@ -738,22 +738,22 @@ type Config struct {
 	// RateLimit encapsulates rate limit configuration definitions.
 	RateLimit
 
-	// Allows you to dynamically configure analytics expiration on a per organisation level
+	// Allows you to dynamically configure analytics expiration on a per organization level
 	EnforceOrgDataAge bool `json:"enforce_org_data_age"`
 
-	// Allows you to dynamically configure detailed logging on a per organisation level
+	// Allows you to dynamically configure detailed logging on a per organization level
 	EnforceOrgDataDetailLogging bool `json:"enforce_org_data_detail_logging"`
 
-	// Allows you to dynamically configure organisation quotas on a per organisation level
+	// Allows you to dynamically configure organization quotas on a per organization level
 	EnforceOrgQuotas bool `json:"enforce_org_quotas"`
 
 	ExperimentalProcessOrgOffThread bool `json:"experimental_process_org_off_thread"`
 
-	// The monitor section is useful if you wish to enforce a global trigger limit on organisation and user quotas.
+	// The monitor section is useful if you wish to enforce a global trigger limit on organization and user quotas.
 	// This feature will trigger a webhook event to fire when specific triggers are reached.
-	// Triggers can be global (set in the node), by organisation (set in the organisation session object) or by key (set in the key session object)
+	// Triggers can be global (set in the node), by organization (set in the organization session object) or by key (set in the key session object)
 	//
-	// While Organisation-level and Key-level triggers can be tiered (e.g. trigger at 10%, trigger at 20%, trigger at 80%), in the node-level configuration only a global value can be set.
+	// While Organization-level and Key-level triggers can be tiered (e.g. trigger at 10%, trigger at 20%, trigger at 80%), in the node-level configuration only a global value can be set.
 	// If a global value and specific trigger level are the same the trigger will only fire once:
 	//
 	// ```
@@ -790,7 +790,7 @@ type Config struct {
 
 	// If AllowMasterKeys is set to true, session objects (key definitions) that do not have explicit access rights set
 	// will be allowed by Tyk. This means that keys that are created have access to ALL APIs, which in many cases is
-	// unwanted behaviour unless you are sure about what you are doing.
+	// unwanted behavior unless you are sure about what you are doing.
 	AllowMasterKeys bool `json:"allow_master_keys"`
 
 	ServiceDiscovery ServiceDiscoveryConf `json:"service_discovery"`