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/apps/README.md

@@ -1,4 +1,6 @@
-# Programming Model
+---
+title: Programming Model
+---
 
 An _app_ interacts with a Solana cluster by sending it _transactions_ with one or more _instructions_. The Solana _runtime_ passes those instructions to _programs_ deployed by app developers beforehand. An instruction might, for example, tell a program to transfer _lamports_ from one _account_ to another or create an interactive contract that governs how lamports are transferred. Instructions are executed sequentially and atomically for each transaction. If any instruction is invalid, all account changes in the transaction are discarded.
 
@@ -18,7 +20,7 @@ Each instruction specifies a single program account \(which must be marked execu
 
 ## Deploying Programs to a Cluster
 
-![SDK tools](../.gitbook/assets/sdk-tools.svg)
+![SDK tools](/img/sdk-tools.svg)
 
 As shown in the diagram above, a program author creates a program and compiles it to an ELF shared object containing BPF bytecode and uploads it to the Solana cluster with a special _deploy_ transaction. The cluster makes it available to clients via a _program ID_. The program ID is a _address_ specified when deploying and is used to reference the program in subsequent transactions.
 

docs/src/apps/builtins/README.md

@@ -1,4 +1,6 @@
-# Builtin Programs
+---
+title: Builtin Programs
+---
 
 Solana contains a small handful of builtin programs, which are required to run
 validator nodes. Unlike third-party programs, the builtin programs are part of
@@ -18,15 +20,15 @@ programs, as well include instructions from third-party programs.
 
 Create accounts and transfer lamports between them
 
-* Program ID: `11111111111111111111111111111111`
-* Instructions: [SystemInstruction](https://docs.rs/solana-sdk/LATEST_SOLANA_RELEASE_VERSION/solana_sdk/system_instruction/enum.SystemInstruction.html)
+- Program ID: `11111111111111111111111111111111`
+- Instructions: [SystemInstruction](https://docs.rs/solana-sdk/LATEST_SOLANA_RELEASE_VERSION/solana_sdk/system_instruction/enum.SystemInstruction.html)
 
 ## Config Program
 
 Add configuration data to the chain and the list of public keys that are permitted to modify it
 
-* Program ID: `Config1111111111111111111111111111111111111`
-* Instructions: [config_instruction](https://docs.rs/solana-config-program/LATEST_SOLANA_RELEASE_VERSION/solana_config_program/config_instruction/index.html)
+- Program ID: `Config1111111111111111111111111111111111111`
+- Instructions: [config_instruction](https://docs.rs/solana-config-program/LATEST_SOLANA_RELEASE_VERSION/solana_config_program/config_instruction/index.html)
 
 Unlike the other programs, the Config program does not define any individual
 instructions. It has just one implicit instruction, a "store" instruction. Its
@@ -37,25 +39,25 @@ data to store in it.
 
 Create stake accounts and delegate it to validators
 
-* Program ID: `Stake11111111111111111111111111111111111111`
-* Instructions: [StakeInstruction](https://docs.rs/solana-stake-program/LATEST_SOLANA_RELEASE_VERSION/solana_stake_program/stake_instruction/enum.StakeInstruction.html)
+- Program ID: `Stake11111111111111111111111111111111111111`
+- Instructions: [StakeInstruction](https://docs.rs/solana-stake-program/LATEST_SOLANA_RELEASE_VERSION/solana_stake_program/stake_instruction/enum.StakeInstruction.html)
 
 ## Vote Program
 
 Create vote accounts and vote on blocks
 
-* Program ID: `Vote111111111111111111111111111111111111111`
-* Instructions: [VoteInstruction](https://docs.rs/solana-vote-program/LATEST_SOLANA_RELEASE_VERSION/solana_vote_program/vote_instruction/enum.VoteInstruction.html)
+- Program ID: `Vote111111111111111111111111111111111111111`
+- Instructions: [VoteInstruction](https://docs.rs/solana-vote-program/LATEST_SOLANA_RELEASE_VERSION/solana_vote_program/vote_instruction/enum.VoteInstruction.html)
 
 ## BPF Loader
 
 Add programs to the chain.
 
-* Program ID: `BPFLoader1111111111111111111111111111111111`
-* Instructions: [LoaderInstruction](https://docs.rs/solana-sdk/LATEST_SOLANA_RELEASE_VERSION/solana_sdk/loader_instruction/enum.LoaderInstruction.html)
+- Program ID: `BPFLoader1111111111111111111111111111111111`
+- Instructions: [LoaderInstruction](https://docs.rs/solana-sdk/LATEST_SOLANA_RELEASE_VERSION/solana_sdk/loader_instruction/enum.LoaderInstruction.html)
 
 The BPF Loader marks itself as its "owner" of the executable account it
 creates to store your program. When a user invokes an instruction via a
 program ID, the Solana runtime will load both your executable account and its
 owner, the BPF Loader. The runtime then passes your program to the BPF Loader
-to process the instruction.
+to process the instruction.

docs/src/apps/drones.md

@@ -1,4 +1,6 @@
-# Drones
+---
+title: Drones
+---
 
 This section defines an off-chain service called a _drone_, which acts as custodian of a user's private key. In its simplest form, it can be used to create _airdrop_ transactions, a token transfer from the drone's account to a client's account.
 
@@ -20,7 +22,7 @@ Note: the Solana cluster will not parallelize transactions funded by the same fe
 
 ## Attack vectors
 
-### Invalid recent\_blockhash
+### Invalid recent_blockhash
 
 The drone may prefer its airdrops only target a particular Solana cluster. To do that, it listens to the cluster for new entry IDs and ensure any requests reference a recent one.
 
@@ -41,4 +43,3 @@ A client may request multiple airdrops before the first has been submitted to th
 If the transaction data size is smaller than the size of the returned signature \(or descriptive error\), a single client can flood the network. Considering that a simple `Transfer` operation requires two public keys \(each 32 bytes\) and a `fee` field, and that the returned signature is 64 bytes \(and a byte to indicate `Ok`\), consideration for this attack may not be required.
 
 In the current design, the drone accepts TCP connections. This allows clients to DoS the service by simply opening lots of idle connections. Switching to UDP may be preferred. The transaction data will be smaller than a UDP packet since the transaction sent to the Solana cluster is already pinned to using UDP.
-

docs/src/apps/javascript-api.md

@@ -1,4 +1,5 @@
-# JavaScript API
+---
+title: JavaScript API
+---
 
 See [solana-web3](https://solana-labs.github.io/solana-web3.js/).
-

docs/src/apps/rent.md

@@ -1,4 +1,6 @@
-# Storage Rent for Accounts
+---
+title: Storage Rent for Accounts
+---
 
 Keeping accounts alive on Solana incurs a storage cost called _rent_ because the cluster must actively maintain the data to process any future transactions on it. This is different from Bitcoin and Ethereum, where storing accounts doesn't incur any costs.
 

docs/src/apps/tictactoe.md

@@ -1,4 +1,6 @@
-# Example: Tic-Tac-Toe
+---
+title: "Example: Tic-Tac-Toe"
+---
 
 [Click here to play Tic-Tac-Toe](https://solana-example-tictactoe.herokuapp.com/) on the Solana testnet. Open the link and wait for another player to join, or open the link in a second browser tab to play against yourself. You will see that every move a player makes stores a transaction on the ledger.
 
@@ -19,4 +21,3 @@ Next, follow the steps in the git repository's [README](https://github.com/solan
 ## Getting lamports to users
 
 You may have noticed you interacted with the Solana cluster without first needing to acquire lamports to pay transaction fees. Under the hood, the web app creates a new ephemeral identity and sends a request to an off-chain service for a signed transaction authorizing a user to start a new game. The service is called a _drone_. When the app sends the signed transaction to the Solana cluster, the drone's lamports are spent to pay the transaction fee and start the game. In a real world app, the drone might request the user watch an ad or pass a CAPTCHA before signing over its lamports.
-

docs/src/apps/webwallet.md

@@ -1,4 +1,6 @@
-# Example Client: Web Wallet
+---
+title: "Example Client: Web Wallet"
+---
 
 ## Build and run a web wallet locally
 
@@ -13,4 +15,3 @@ $ git checkout $TAG
 ```
 
 Next, follow the steps in the git repository's [README](https://github.com/solana-labs/example-webwallet/blob/master/README.md).
-