docs: Fixed broken links (#26083)

Signed-off-by: Kevin Joe Harris <kevinjoeharris1@gmail.com>
Signed-off-by: S Kevin Joe Harris <59595928+Kevinjoeharris@users.noreply.github.com>
Co-authored-by: Regina Voloshin <regina.voloshin@codefresh.io>

docs/faq.md

@@ -19,7 +19,7 @@ which might cause health check to return `Progressing` state instead of `Healthy
 
 * `Ingress` is considered healthy if `status.loadBalancer.ingress` list is non-empty, with at least one value
   for `hostname` or `IP`. Some ingress controllers
-  ([contour](https://github.com/heptio/contour/issues/403)
+  ([contour](https://github.com/projectcontour/contour/issues/403)
   , [traefik](https://github.com/argoproj/argo-cd/issues/968#issuecomment-451082913)) don't update
   `status.loadBalancer.ingress` field which causes `Ingress` to stuck in `Progressing` state forever.
 

docs/proposals/multiple-sources-for-applications-ui.md

@@ -37,7 +37,7 @@ enabled the UI to tolerate multi-source applications with the new Sources field,
 
 Here are the current restrictions and limitations of the UI when applications with multiple sources are used:
 
-1. The application’s details page (for [example](https://cd.apps.argoproj.io/applications/argocd/guestbook?view=tree&node=argoproj.io%2FApplication%2Fargocd%2Fguestbook%2F0&resource=)) 
+1. The application’s details page 
 currently shows one ApplicationSource, regardless of whether the application has one source or multiple sources. With the PR 10432 implementation, if the application has multiple sources,
 the UI displays only the first of the sources. Also, in particular, in the Summary tab, the source parameters are non-editable. 
 
@@ -50,7 +50,7 @@ rollback which includes [controller and UI changes](https://github.com/argoproj/
 
 Thus, multiple source applications are not considered first class citizens in the UI.
 
-Note, see the [Open Questions](https://github.com/argoproj/argo-cd/docs/proposals/multiple-sources-for-applications-ui.md#open-questions) 
+Note, see the [Open Questions](#open-questions) 
 section for concerns regarding the priority or value of some of the above changes.
 
 ## Motivation

docs/proposals/parameterized-config-management-plugins.md

@@ -302,7 +302,7 @@ Environment variable names are set according to these rules:
 1. If a parameter is a `string`, the format is `PARAM_{escaped(name)}` (`escaped` is defined below).
 2. If a parameter is an `array`, the format is `PARAM_{escaped(name_{index})}` (where the first index is 0).
 3. If a parameter is a `map`, the format is `PARAM_{escaped(name_key)}`.
-4. If an escaped env var name matches one in the [build environment](https://argo-cd-docs.readthedocs.io/en/latest/user-guide/build-environment/),
+4. If an escaped env var name matches one in the [build environment](https://argo-cd.readthedocs.io/en/latest/user-guide/build-environment/),
    the build environment variable wins.
 5. If more than one parameter name produces the same env var name, the env var later in the list wins.
 

docs/proposals/rebalancing-clusters-across-shards-dynamically.md

@@ -102,7 +102,7 @@ How will this work?
 
 ### Cons
 
-* ~~Possibility of race conditions while flagging the shard as Unhealthy during the heartbeat process. Although this can be handled using the [distributed locks](https://redis.io/docs/manual/patterns/distributed-locks/) in Redis.~~
+* ~~Possibility of race conditions while flagging the shard as Unhealthy during the heartbeat process. Although this can be handled using the [distributed locks](https://redis.io/docs/latest/develop/clients/patterns/distributed-locks/) in Redis.~~
 As we are using ConfigMap, this Con get's removed. Kubernetes would give conflict errors in case multiple edits are tried on the ConfigMap at the same time. We can leverage this error messages to avoid race conditions.
 
 * ~~In scenarios when Redis becomes unavailable, the heartbeat mechanism will pause working till the redis comes back online again. This will also pause the dynamic redistribution of clusters till Redis comes back online. The redistribution of clusters will be triggered again when Redis comes back online.~~ We would not see this issue by using ConfigMap instead of Redis.

docs/security_considerations.md

@@ -32,7 +32,7 @@ no fix yet.
 
 ## Known Issues And Workarounds
 
-A recent security audit (thanks a lot to [Matt Hamilton](https://github.com/Eriner) of [https://soluble.ai](https://soluble.ai) )
+A recent security audit (thanks a lot to [Matt Hamilton](https://github.com/Eriner) of Soluble AI (acquired by https://www.fortinet.com) )
 has revealed several limitations in Argo CD which could compromise security.
 Most of the issues are related to the built-in user management implementation.
 

docs/user-guide/sync-options.md

@@ -334,7 +334,7 @@ When client-side apply migration is enabled:
    - Move the 'last-applied-configuration' annotation to be managed by the specified manager
    - Perform the server-side apply, which will auto migrate all the fields under the manager that owns the 'last-applied-configuration' annotation.
 
-This feature is based on Kubernetes' [client-side apply migration KEP](https://github.com/alexzielenski/enhancements/blob/03df8820b9feca6d2cab78e303c99b2c9c0c4c5c/keps/sig-cli/3517-kubectl-client-side-apply-migration/README.md), which provides the auto migration from client-side to server-side apply.
+This feature is based on Kubernetes' [client-side to server-side apply migration](https://kubernetes.io/docs/reference/using-api/server-side-apply/#migration-between-client-side-and-server-side-apply).
 
 ## Fail the sync if a shared resource is found