Move from gitbook to docusaurus, build docs in Travis CI (#10970)

* fix: ignore unknown fields in more RPC responses

* Remove mdbook infrastructure

* Delete gitattributes and other theme related items

Move all docs to /docs folder to support Docusaurus

* all docs need to be moved to /docs

* can be changed in the future

Add Docusaurus infrastructure

* initialize docusaurus repo

Remove trailing whitespace, add support for eslint

Change Docusaurus configuration to support `src`

* No need to rename the folder! Change a setting and we're all good to
go.

* Fixing rebase items

* Remove unneccessary markdown file, fix type

* Some fonts are hard to read. Others, not so much. Rubik, you've been
sidelined. Roboto, into the limelight!

* As much as we all love tutorials, I think we all can navigate around a
markdown file. Say goodbye, `mdx.md`.

* Setup deployment infrastructure

* Move docs job from buildkite to travic

* Fix travis config

* Add vercel token to travis config

* Only deploy docs after merge

* Docker rust env

* Revert "Docker rust env"

This reverts commit f84bc208e807aab1c0d97c7588bbfada1fedfa7c.

* Build CLI usage from docker

* Pacify shellcheck

* Run job on PR and new commits for publication

* Update README

* Fix svg image building

* shellcheck

Co-authored-by: Michael Vines <mvines@gmail.com>
Co-authored-by: Ryan Shea <rmshea@users.noreply.github.com>
Co-authored-by: publish-docs.sh <maintainers@solana.com>

docs/src/implemented-proposals/staking-rewards.md

@@ -1,16 +1,18 @@
-# Staking Rewards
+---
+title: Staking Rewards
+---
 
 A Proof of Stake \(PoS\), \(i.e. using in-protocol asset, SOL, to provide secure consensus\) design is outlined here. Solana implements a proof of stake reward/security scheme for validator nodes in the cluster. The purpose is threefold:
 
-* Align validator incentives with that of the greater cluster through
+- Align validator incentives with that of the greater cluster through
 
   skin-in-the-game deposits at risk
 
-* Avoid 'nothing at stake' fork voting issues by implementing slashing rules
+- Avoid 'nothing at stake' fork voting issues by implementing slashing rules
 
   aimed at promoting fork convergence
 
-* Provide an avenue for validator rewards provided as a function of validator
+- Provide an avenue for validator rewards provided as a function of validator
 
   participation in the cluster.
 
@@ -22,13 +24,13 @@ Solana's ledger validation design is based on a rotating, stake-weighted selecte
 
 To become a Solana validator, one must deposit/lock-up some amount of SOL in a contract. This SOL will not be accessible for a specific time period. The precise duration of the staking lockup period has not been determined. However we can consider three phases of this time for which specific parameters will be necessary:
 
-* _Warm-up period_: which SOL is deposited and inaccessible to the node,
+- _Warm-up period_: which SOL is deposited and inaccessible to the node,
 
   however PoH transaction validation has not begun. Most likely on the order of
 
   days to weeks
 
-* _Validation period_: a minimum duration for which the deposited SOL will be
+- _Validation period_: a minimum duration for which the deposited SOL will be
 
   inaccessible, at risk of slashing \(see slashing rules below\) and earning
 
@@ -36,7 +38,7 @@ To become a Solana validator, one must deposit/lock-up some amount of SOL in a c
 
   year.
 
-* _Cool-down period_: a duration of time following the submission of a
+- _Cool-down period_: a duration of time following the submission of a
 
   'withdrawal' transaction. During this period validation responsibilities have
 
@@ -53,4 +55,3 @@ Solana's trustless sense of time and ordering provided by its PoH data structure
 As discussed in the [Economic Design](../implemented-proposals/ed_overview/README.md) section, annual validator interest rates are to be specified as a function of total percentage of circulating supply that has been staked. The cluster rewards validators who are online and actively participating in the validation process throughout the entirety of their _validation period_. For validators that go offline/fail to validate transactions during this period, their annual reward is effectively reduced.
 
 Similarly, we may consider an algorithmic reduction in a validator's active amount staked amount in the case that they are offline. I.e. if a validator is inactive for some amount of time, either due to a partition or otherwise, the amount of their stake that is considered ‘active’ \(eligible to earn rewards\) may be reduced. This design would be structured to help long-lived partitions to eventually reach finality on their respective chains as the % of non-voting total stake is reduced over time until a supermajority can be achieved by the active validators in each partition. Similarly, upon re-engaging, the ‘active’ amount staked will come back online at some defined rate. Different rates of stake reduction may be considered depending on the size of the partition/active set.
-