Backport of update serf links into release/1.19.x (#21799)

* no-op commit due to failed cherry-picking

* update serf links (#21797)

* update serf links

* add .markdown file extension

* update serf links to use /blob/master/

* fix broken links

---------

Co-authored-by: github-team-consul-core <github-team-consul-core@hashicorp.com>

---------

Co-authored-by: temp <temp@hashicorp.com>
Co-authored-by: John Murret <john.murret@hashicorp.com>

internal/gossip/libserf/serf.go

@@ -29,7 +29,7 @@ func DefaultConfig() *serf.Config {
 	// This gives leaves some time to propagate through the cluster before
 	// we shut down. The value was chosen to be reasonably short, but to
 	// allow a leave to get to over 99.99% of the cluster with 100k nodes
-	// (using https://www.serf.io/docs/internals/simulator.html).
+	// (using https://github.com/hashicorp/serf/blob/master/docs/internals/simulator.html.erb).
 	base.LeavePropagateDelay = 3 * time.Second
 
 	return base

website/content/docs/architecture/coordinates.mdx

@@ -14,10 +14,10 @@ very simple calculation. This allows for many useful applications, such as findi
 the service node nearest a requesting node, or failing over to services in the next
 closest datacenter.
 
-All of this is provided through the use of the [Serf library](https://www.serf.io/).
+All of this is provided through the use of the [Serf library](https://github.com/hashicorp/serf/).
 Serf's network tomography is based on ["Vivaldi: A Decentralized Network Coordinate System"](http://www.cs.ucsb.edu/~ravenben/classes/276/papers/vivaldi-sigcomm04.pdf),
 with some enhancements based on other research. There are more details about
-[Serf's network coordinates here](https://www.serf.io/docs/internals/coordinates.html).
+[Serf's network coordinates here](https://github.com/hashicorp/serf/blob/master/docs/internals/coordinates.html.markdown).
 
 ## Network Coordinates in Consul
 

website/content/docs/architecture/gossip.mdx

@@ -9,15 +9,15 @@ description: >-
 
 Consul uses a [gossip protocol](https://en.wikipedia.org/wiki/Gossip_protocol)
 to manage membership and broadcast messages to the cluster. The protocol, membership management, and message broadcasting is provided
-through the [Serf library](https://www.serf.io/). The gossip protocol
+through the [Serf library](https://github.com/hashicorp/serf/). The gossip protocol
 used by Serf is based on a modified version of the
 [SWIM (Scalable Weakly-consistent Infection-style Process Group Membership)](https://www.cs.cornell.edu/projects/Quicksilver/public_pdfs/SWIM.pdf) protocol.
-Refer to the [Serf documentation](https://www.serf.io/docs/internals/gossip.html) for additional information about the gossip protocol.
+Refer to the [Serf documentation](https://github.com/hashicorp/serf/blob/master/docs/internals/gossip.html.markdown) for additional information about the gossip protocol.
 
 ## Gossip in Consul
 
 Consul uses a LAN gossip pool and a WAN gossip pool to perform different functions. The pools
-are able to perform their functions by leveraging an embedded [Serf](https://www.serf.io/)
+are able to perform their functions by leveraging an embedded [Serf](https://github.com/hashicorp/serf/)
 library. The library is abstracted and masked by Consul to simplify the user experience,
 but developers may find it useful to understand how the library is leveraged.
 
@@ -52,5 +52,5 @@ For more details about Lifeguard, please see the
 [Making Gossip More Robust with Lifeguard](https://www.hashicorp.com/blog/making-gossip-more-robust-with-lifeguard/)
 blog post, which provides a high level overview of the HashiCorp Research paper
 [Lifeguard : SWIM-ing with Situational Awareness](https://arxiv.org/abs/1707.00788). The
-[Serf gossip protocol guide](https://www.serf.io/docs/internals/gossip.html#lifeguard)
+[Serf gossip protocol guide](https://github.com/hashicorp/serf/blob/master/docs/internals/gossip.html.markdown#lifeguard-enhancements)
 also provides some lower-level details about the gossip protocol and Lifeguard.

website/content/docs/install/glossary.mdx

@@ -51,7 +51,7 @@ and our implementation is described [here](/consul/docs/architecture/consensus).
 
 ## Gossip
 
-Consul is built on top of [Serf](https://www.serf.io/) which provides a full
+Consul is built on top of [Serf](https://github.com/hashicorp/serf/) which provides a full
 [gossip protocol](https://en.wikipedia.org/wiki/Gossip_protocol) that is used for multiple purposes.
 Serf provides membership, failure detection, and event broadcast. Our use of these
 is described more in the [gossip documentation](/consul/docs/architecture/gossip). It is enough to know

website/content/docs/troubleshoot/faq.mdx

@@ -69,7 +69,7 @@ and [`disable_update_check`](/consul/docs/agent/config/config-files#disable_upda
 
 ### Q: Does Consul rely on UDP Broadcast or Multicast?
 
-Consul uses the [Serf](https://www.serf.io) gossip protocol which relies on
+Consul uses the [Serf](https://github.com/hashicorp/serf/) gossip protocol which relies on
 TCP and UDP unicast. Broadcast and Multicast are rarely available in a
 multi-tenant or cloud network environment. For that reason, Consul and Serf
 were both designed to avoid any dependence on those capabilities.