chore: exclude and update 40x links (#1632)

.github/scripts/muffet.sh

@@ -33,4 +33,16 @@ muffet http://localhost:1313 \
   --exclude "http[s]*://127\.0\.0*" \
   --exclude "https://docs.google.com/spreadsheets/d/12345ABCDEF/.*" \
   --exclude "https://docs.google.com/document/d/14AuJ7SerLuOPESBjQlJqpBtzwSAoVf5ykTT7fjyJBT0/*" \
+  --exclude "https://tools.google.com.*" \
+  --exclude "http[s]*://.*docs.couchdb.org.*" \
+  --exclude "http[s]*://.*oppiamobile.readthedocs.io.*" \
+  --exclude "http[s]*://.*africastalking.com*" \
+  --exclude "http://www.hl7.org*" \
+  --exclude "https://garticphone.com/" \
+  --exclude "http[s]*://.*borgbackup.readthedocs.io.*" \
+  --exclude "https://www.tableau.com" \
+  --exclude "https://doi.org/10.1080/02681102.2019.1667289" \
+  --exclude "https://journals.sagepub.com/doi/full/10.1177/20552076231194924" \
+  --exclude "http[s]*://.*udemy.com.*" \
+  --exclude "http[s]*://.*udacity.com.*" \
   --exclude "https://drive.google.com/file/d/1YPXoba9gVmD7SP-X88PpJIsIVGvY86_G.*" 

content/en/building/features/integrations/rapidpro.md

@@ -10,7 +10,7 @@ aliases:
   - /apps/features/integrations/rapidpro/
 ---
 
-[RapidPro](https://rapidpro.io/) is a software product that allows you to visually build logic to support interactive messaging flows. The flows support a variety of technologies such as: SMS, USSD, IVR, Telegram, Facebook Messenger, and WhatsApp. RapidPro is open source and provides an [API](https://community.rapidpro.io/rapidpros-api/) to integrate with other applications. To learn more about the platform, check out RapidPro on [GitHub](https://rapidpro.github.io/rapidpro/), their [Community](https://community.rapidpro.io/) website, or join their Google [Group](https://groups.google.com/g/rapidpro). 
+[RapidPro](https://rapidpro.io/) is a software product that allows you to visually build logic to support interactive messaging flows. The flows support a variety of technologies such as: SMS, USSD, IVR, Telegram, Facebook Messenger, and WhatsApp. RapidPro is open source and provides an [API](https://rapidpro.io/api/v2/) to integrate with other applications. To learn more about the platform, check out RapidPro on [GitHub](https://rapidpro.github.io/rapidpro/) or join their Google [Group](https://groups.google.com/g/rapidpro). 
 
 ## Overview
 CHT-based [SMS workflows]({{< ref "building/concepts/workflows#sms-messaging" >}}) can be configured to support registering of new patients or pregnancies, recording outcomes of visits, confirmation via auto-responses, and scheduling reminders. Some projects are designed entirely around SMS workflows. The CHT also supports person to person SMS [messaging]({{< ref "building/features/messaging" >}}) from the Messages tab. 

content/en/building/guides/integrations/rapidpro.md

@@ -14,7 +14,7 @@ aliases:
 
 [RapidPro](https://app.rapidpro.io/) is the open-source platform that powers [TextIt](https://textit.com/), developed by UNICEF and Nyaruka. RapidPro allows you to visually build messaging workflows for mobile-based services. Review RapidPro’s documentation to familiarize yourself with various components that include the [API](https://rapidpro.io/api/v2/). Before you embark on designing an integrated RapidPro/CHT workflow, you should start by understanding the needs of your users, identifying a problem to solve, and establishing goals. While an integrated RapidPro/CHT workflow can open up many powerful and personalized messaging capabilities, introducing an additional technology solution does come with complexities and cost. A good way to mitigate some of the complexities of setting up and [hosting](https://rapidpro.github.io/rapidpro/docs/hosting/) RapidPro yourself is to utilize a SaaS solution such as [TextIt](https://textit.in/). TextIt offers transparent per message [pricing](https://textit.com/pricing) and free credits to start off.
 
-Coming up with a design to accommodate user needs requires a detailed understanding of the capabilities of both systems and conceptually where it makes sense to introduce interactions between them. Below we introduce some of the key concepts in RapidPro, but to learn more you can take one of their [online courses](https://community.rapidpro.io/online-courses/), watch some of their [videos](https://community.rapidpro.io/videos/), and check out their [deployment toolkit](https://community.rapidpro.io/deployment-toolkit/).
+Coming up with a design to accommodate user needs requires a detailed understanding of the capabilities of both systems and conceptually where it makes sense to introduce interactions between them. Below we introduce some of the key concepts in RapidPro, but to learn more you can have a look at their [documentation](https://rapidpro.github.io/rapidpro/docs/).
 
 ## RapidPro Concepts
 

content/en/building/guides/interoperability/fhir.md

@@ -170,7 +170,7 @@ In this example, a `danger signs` question is converted into `Observations` wher
 ## Inbound Patients
 
 It is also possbile to create patients in the CHT from patients that were created in external systems.
-Patients in CHT applications are represented as [contacts](building/contact-management/contacts/), and require a parent to be assigned to a CHW, facility, or other location. This requires a mediator to have the ids of contacts in CHT and currently cannot be done automatically by the default mediator. A custom mediator needs to be created which assigns a field to use as the `parent_id`.
+Patients in CHT applications are represented as [contacts]({{< relref "/building/contact-management/contacts" >}}), and require a parent to be assigned to a CHW, facility, or other location. This requires a mediator to have the ids of contacts in CHT and currently cannot be done automatically by the default mediator. A custom mediator needs to be created which assigns a field to use as the `parent_id`.
 
 To create data in CHT, a mediator converts a FHIR `Patient` to a json object that it submits as a request to [the records API](/building/reference/api/#records).
 This requires a [form](/building/reference/app-settings/forms/) to be configured in the CHT; the incoming data will be saved as a report.

content/en/contribute/code/_index.md

@@ -76,7 +76,7 @@ If you follow these guidelines when reporting an issue to us, we commit to:
 
 #### Scope
 
-- https://alpha.dev.medicmobile.org
+A local CHT instance is included in the scope. Follow the [manual instructions]({{< relref "hosting/4.x/app-developer" >}}) to set up a CHT instance. 
 
 #### Out of scope
 

content/en/contribute/code/core/dev-environment.md

@@ -186,7 +186,7 @@ If you had issues with following the above steps, check out these links for how
 * [xsltproc](http://www.sagehill.net/docbookxsl/InstallingAProcessor.html) 
 * [python 2.7](https://www.python.org/downloads/)
 * [Docker](https://docs.docker.com/engine/install/)
-* [CouchDB](https://docs.couchdb.org/en/2.3.1/install/index.html) - OS package instead of in Docker - you **MUST** use CouchDB 2.x! We still strongly recommend using Docker.
+* [CouchDB](https://docs.couchdb.org/en/stable/install/index.html) - OS package instead of in Docker - you **MUST** use CouchDB 2.x for CHT < 4.4! We still strongly recommend using Docker.
 
 ### Ubuntu 18.04
 
@@ -224,7 +224,7 @@ Parts of the command:
 - `-v` maps where couchdb stores data to your local file system to ensure persistence without depending on the container, using the path *before* the `:` (the path after the colon is the internal path inside the docker image). This should be somewhere you have write access to, and want this data to be stored. The second mounted volume is for the couch configuration, which will retain settings if your container is removed. This is especially important after running the command to secure the instance (done in steps below).
 - `apache/couchdb:2` will install the latest package for CouchDB 2.x
 
-Once this downloads and starts, you will need to [initialise CouchDB](http://localhost:5984/_utils/#/setup) as noted in [their install instructions](https://docs.couchdb.org/en/2.3.1/setup/index.html#setup).
+Once this downloads and starts, you will need to [initialise CouchDB](http://localhost:5984/_utils/#/setup) as noted in [their install instructions](https://docs.couchdb.org/en/stable/setup/index.html#setup).
 
 You can use `docker stop medic-couchdb` to stop it and `docker start medic-couchdb` to start it again. Remember that you'll need to start it whenever you restart your OS, which might not be the case if you use a normal OS package. `docker rm medic-couchdb` will totally remove the container.
 

content/en/hosting/3.x/self-hosting.md

@@ -166,6 +166,6 @@ Regular backups should be made of the `/srv` directory to have holistic and easy
 * ./nginx
 * ./passwd
 
-To make backups of just CouchDB data outside of the CHT docker infrastructure, please see [CouchDB's Backup docs for 2.3.1](https://docs.couchdb.org/en/2.3.1/maintenance/backups.html). Please note:
+To make backups of just CouchDB data outside of the CHT docker infrastructure, please see [CouchDB's Backup docs for 2.3.1](https://web.archive.org/web/20220527070753/https://docs.couchdb.org/en/2.3.1/maintenance/backups.html). Please note:
 * CouchDB data files are in `/srv/storage/medic-core/couchdb/data` in the `medic-os` container.
 * Backing up via replication is discouraged as restored DBs can cause offline users to restart replication from zero. Use file backups instead. 

content/en/hosting/analytics/couch2pg-to-cht-sync-migration.md

@@ -15,7 +15,7 @@ This page outlines guidelines for migrating from [couch2pg](https://github.com/m
 
 ## Key Considerations
 - **Kubernetes vs Docker Compose**: CHT Sync provides configurations to support deployment to test and production environments with Docker Compose or Kubernetes. You can read more about the CHT hosting options in the [dedicated page]({{< relref "hosting/kubernetes-vs-docker" >}}). 
-- **Server resources**: To minimize downtime, running both couch2pg and CHT Sync in parallel during the migration process is recommended. With this in mind, ensure that the server and [database resources]({{< relref "hosting/analytics/setup-kubernetes#database-disk-space-requirements" >}}) are sufficient to handle the load.
+- **Server resources**: To minimize downtime, running both couch2pg and CHT Sync in parallel during the migration process is recommended. With this in mind, ensure that the server and [database resources]({{< relref "hosting/analytics/building-dbt-models#database-disk-space-requirements" >}}) are sufficient to handle the load.
 - **dbt modelling**: Avoid the temptation to model new dbt models after existing SQL views and tables. Instead, take the opportunity to re-evaluate the data needs and design new models that are more efficient and effective. Think of what data needs to be shown and how it should be shown in data visualization tools and use that to guide the design of the new models.
 - **Testing**: After migrating, thoroughly test the new dbt models to ensure that they work as expected. Refer to the [testing dbt models guide]({{< relref "hosting/analytics/building-dbt-models" >}}) for guidelines on testing.
 - **Feedback**: Provide any feedback and create issues for errors or bugs encountered in the [cht-sync](https://github.com/medic/cht-sync) and [cht-pipeline](https://github.com/medic/cht-pipeline/) repositories to improve the tools.