Simplify link validator config (#1381)

docs/src/main/paradox/persistence-query.md

@@ -202,7 +202,7 @@ Java
 
 ## Performance and denormalization
 
-When building systems using @ref:[Event Sourcing](typed/persistence.md#event-sourcing-concepts) and CQRS ([Command & Query Responsibility Segregation](https://docs.microsoft.com/en-us/previous-versions/msp-n-p/jj554200%28v=pandp.10%29)) techniques
+When building systems using @ref:[Event Sourcing](typed/persistence.md#event-sourcing-concepts) and CQRS ([Command & Query Responsibility Segregation](https://learn.microsoft.com/en-us/previous-versions/msp-n-p/jj554200%28v=pandp.10%29)) techniques
 it is tremendously important to realise that the write-side has completely different needs from the read-side,
 and separating those concerns into datastores that are optimised for either side makes it possible to offer the best
 experience for the write and read sides independently.

docs/src/main/paradox/persistence-schema-evolution.md

@@ -45,7 +45,7 @@ evolution feel free to submit Pull Requests to this page to extend it.
 
 In recent years we have observed a tremendous move towards immutable append-only datastores, with event-sourcing being
 the prime technique successfully being used in these settings. For an excellent overview why and how immutable data makes scalability
-and systems design much simpler you may want to read Pat Helland's excellent [Immutability Changes Everything](http://cidrdb.org/cidr2015/Papers/CIDR15_Paper16.pdf) whitepaper.
+and systems design much simpler you may want to read Pat Helland's excellent [Immutability Changes Everything](https://cidrdb.org/cidr2015/Papers/CIDR15_Paper16.pdf) whitepaper.
 
 Since with [Event Sourcing](https://martinfowler.com/eaaDev/EventSourcing.html) the **events are immutable** and usually never deleted – the way schema evolution is handled
 differs from how one would go about it in a mutable database setting (e.g. in typical CRUD database applications).

docs/src/main/paradox/stream/reactive-streams-interop.md

@@ -136,5 +136,5 @@ An incomplete list of other implementations:
 
  * [Reactor (1.1+)](https://github.com/reactor/reactor)
  * [RxJava](https://github.com/ReactiveX/RxJavaReactiveStreams)
- * [Ratpack](https://www.ratpack.io/manual/current/streams.html)
+ * [Ratpack](https://ratpack.io/manual/current/streams.html)
  * [Slick](https://scala-slick.org/)

docs/src/main/paradox/typed/failure-detector.md

@@ -5,7 +5,7 @@
 Remote DeathWatch uses heartbeat messages and the failure detector to detect network failures and JVM crashes. 
 
 The heartbeat arrival times are interpreted by an implementation of
-[The Phi Accrual Failure Detector](https://pdfs.semanticscholar.org/11ae/4c0c0d0c36dc177c1fff5eb84fa49aa3e1a8.pdf) by Hayashibara et al.
+[The Phi Accrual Failure Detector](https://www.semanticscholar.org/paper/The-spl-phi-accrual-failure-detector-Hayashibara-D%C3%A9fago/11ae4c0c0d0c36dc177c1fff5eb84fa49aa3e1a8?p2df) by Hayashibara et al.
 
 ## Failure Detector Heartbeats
 

docs/src/main/paradox/typed/routers.md

@@ -130,7 +130,7 @@ An optional parameter `preferLocalRoutees` can be used for this strategy. Router
 ### Consistent Hashing
 
 Uses [consistent hashing](https://en.wikipedia.org/wiki/Consistent_hashing) to select a routee based
-on the sent message. This [article](http://www.tom-e-white.com/2007/11/consistent-hashing.html)
+on the sent message. This [article](https://www.tom-e-white.com/2007/11/consistent-hashing.html)
 gives good insight into how consistent hashing is implemented.
 
 Currently you have to define hashMapping of the router to map incoming messages to their consistent