Website: GH-751 Link to anti-entropy doc everywhere that the term is used.

website/source/docs/agent/http/agent.html.markdown

@@ -11,8 +11,8 @@ description: >
 The Agent endpoints are used to interact with the local Consul agent. Usually,
 services and checks are registered with an agent which then takes on the
 burden of keeping that data synchronized with the cluster.  For example, the
-agent registers services and checks with the Catalog and performs anti-entropy
+agent registers services and checks with the Catalog and performs
-to recover from outages.
+[anti-entropy](/docs/internals/anti-entropy.html) to recover from outages.
 
 The following endpoints are supported:
 
@@ -39,7 +39,8 @@ the local agent. These checks were either provided through configuration files
 or added dynamically using the HTTP API. It is important to note that the checks
 known by the agent may be different from those reported by the Catalog. This is usually
 due to changes being made while there is no leader elected. The agent performs active
-anti-entropy, so in most situations everything will be in sync within a few seconds.
+[anti-entropy](/docs/internals/anti-entropy.html), so in most situations everything will
+be in sync within a few seconds.
 
 This endpoint is hit with a GET and returns a JSON body like this:
 
@@ -65,7 +66,8 @@ the local agent. These services were either provided through configuration files
 or added dynamically using the HTTP API. It is important to note that the services
 known by the agent may be different from those reported by the Catalog. This is usually
 due to changes being made while there is no leader elected. The agent performs active
-anti-entropy, so in most situations everything will be in sync within a few seconds.
+[anti-entropy](/docs/internals/anti-entropy.html), so in most situations everything will
+be in sync within a few seconds.
 
 This endpoint is hit with a GET and returns a JSON body like this:
 

website/source/docs/agent/http/catalog.html.markdown

@@ -29,7 +29,8 @@ tunable consistency modes.
 
 The register endpoint is a low-level mechanism for registering or updating
 entries in the catalog. Note: it is usually preferrable instead to use the
-[agent endpoints](agent.html) for registration as they are simpler and perform anti-entropy.
+[agent endpoints](agent.html) for registration as they are simpler and perform
+[anti-entropy](/docs/internals/anti-entropy.html).
 
 The register endpoint expects a JSON request body to be PUT. The request
 body must look something like:
@@ -93,7 +94,8 @@ If the API call succeeds, a 200 status code is returned.
 
 The deregister endpoint is a low-level mechanism for directly removing
 entries from the Catalog. Note: it is usually preferrable instead to use the
-[agent endpoints](agent.html) for deregistration as they are simpler and perform anti-entropy.
+[agent endpoints](agent.html) for deregistration as they are simpler and perform
+[anti-entropy](/docs/internals/anti-entropy.html).
 
 The deregister endpoint expects a JSON request body to be PUT. The request
 body must look like one of the following:

website/source/docs/guides/outage.html.markdown

@@ -33,7 +33,7 @@ loss is inevitable since data was not replicated to any other servers. This is
 why a single server deploy is **never** recommended.
 
 Any services registered with agents will be re-populated when the new server
-comes online as agents perform anti-entropy.
+comes online as agents perform [anti-entropy](/docs/internals/anti-entropy.html).
 
 ## Failure of a Server in a Multi-Server Cluster