s/avalanche/turbine (#4561)

* s/avalanche/turbine/g

book/src/leader-leader-transition.md

@@ -45,7 +45,7 @@ The upsides compared to guards:
 * The timeout is not fixed.
 
 * The timeout is local to the leader, and therefore can be clever.  The leader's
-heuristic can take into account avalanche performance.
+heuristic can take into account turbine performance.
 
 * This design doesn't require a ledger hard fork to update.
 

book/src/performance-metrics.md

@@ -26,4 +26,4 @@ super majority vote, and when one of its children forks is frozen.
 The node assigns a timestamp to every new fork, and computes the time it took to confirm
 the fork. This time is reflected as validator confirmation time in performance metrics.
 The performance dashboard displays the average of each validator node's confirmation time
-as a time series graph. 
+as a time series graph. 

book/src/staking-rewards.md

@@ -48,7 +48,7 @@ specific parameters will be necessary:
 
 Solana's trustless sense of time and ordering provided by its PoH data
 structure, along with its
-[avalanche](https://www.youtube.com/watch?v=qt_gDRXHrHQ&t=1s) data broadcast
+[turbine](https://www.youtube.com/watch?v=qt_gDRXHrHQ&t=1s) data broadcast
 and transmission design, should provide sub-second transaction confirmation times that scale
 with the log of the number of nodes in the cluster. This means we shouldn't
 have to restrict the number of validating nodes with a prohibitive 'minimum

book/theme/css/chrome.css

@@ -521,4 +521,4 @@ ul#searchresults span.teaser em {
 }
 .content pre {
     padding: 0 28px;
-}
+}

book/theme/css/general.css

@@ -152,4 +152,4 @@ blockquote {
 *:active,
 *:hover {
   outline: none;
-}
+}