doc: Fix mdx format errors generated due to Readme v2 migrations

Changelog-None: Documentation fixes only.

Author: ShahanaFarooqui

doc/beginners-guide/backup-and-recovery/advanced-db-backup.md

@@ -11,26 +11,24 @@ privacy:
 #### Regtest (local, fast-start) option
 
 If you want to experiment with `lightningd`, there's a script to set up a `bitcoind` regtest test network of two local lightning nodes, which provides a convenient `start_ln` helper. See the notes at the top of the `startup_regtest.sh` file for details on how to use it.
-
 ```bash
 . contrib/startup_regtest.sh
 ```
 
 #### Mainnet Option
 
-To test with real bitcoin,  you will need to have a local `bitcoind` node running:
-
+To test with real bitcoin, you will need to have a local `bitcoind` node running:
 ```bash
 bitcoind -daemon
 ```
 
 Wait until `bitcoind` has synchronized with the network.
 
-Make sure that you do not have `walletbroadcast=0` in your `~/.bitcoin/bitcoin.conf`, or you may run into trouble.  
-Notice that running `lightningd` against a pruned node may cause some issues if not managed carefully, see [pruning](doc:bitcoin-core##using-a-pruned-bitcoin-core-node) for more information.
+Make sure that you do not have `walletbroadcast=0` in your `~/.bitcoin/bitcoin.conf`, or you may run into trouble.
 
-You can start `lightningd` with the following command:
+Notice that running `lightningd` against a pruned node may cause some issues if not managed carefully, see [pruning](doc:bitcoin-core#using-a-pruned-bitcoin-core-node) for more information.
 
+You can start `lightningd` with the following command:
 ```bash
 lightningd --network=bitcoin --log-level=debug
 ```
@@ -57,6 +55,6 @@ Useful commands:
 
 Once you've started for the first time, there's a script called `contrib/bootstrap-node.sh` which will connect you to other nodes on the lightning network.
 
-There are also numerous plugins available for Core Lightning which add capabilities: see the [Plugins](doc:plugins) guide, and check out the plugin collection at: <https://github.com/lightningd/plugins>.
+There are also numerous plugins available for Core Lightning which add capabilities: see the [Plugins](doc:plugins) guide, and check out the plugin collection at: https://github.com/lightningd/plugins.
 
 For a less reckless experience, you can encrypt the HD wallet seed: see [HD wallet encryption](doc:backup-and-recovery#hsm-secret-backup).

doc/beginners-guide/beginners-guide.md

@@ -12,7 +12,7 @@ The CLN project has a multitude of interfaces, most of which are generated from
   1. addition of FD passing semantics to allow establishing a new connection between daemons (communication uses [socketpair](https://man7.org/linux/man-pages/man2/socketpair.2.html), so no `connect`)
   2. change the message length prefix from `u16` to `u32`, allowing for messages larger than 65Kb. The CSV files are with the respective sub-daemon and also use [generate-wire.py](https://github.com/ElementsProject/lightning/blob/master/tools/generate-wire.py) to generate encoding, decoding and printing functions
 
-- We describe the JSON-RPC using [JSON Schema](https://json-schema.org/) in the [`doc/schemas`](https://github.com/ElementsProject/lightning/tree/master/doc/schemas) directory. Each method has a `lightning-*.json` for request and response. During tests the `pytest` target will verify responses, however the JSON-RPC methods are _not_ generated (yet?). We do generate various client stubs for languages, using the `msggen`[msggen] tool. More on the generated stubs and utilities below.
+- We describe the JSON-RPC using [JSON Schema](https://json-schema.org/) in the [`doc/schemas`](https://github.com/ElementsProject/lightning/tree/master/doc/schemas) directory. Each method has a `lightning-*.json` for request and response. During tests the `pytest` target will verify responses, however the JSON-RPC methods are _not_ generated (yet?). We do generate various client stubs for languages, using the `msggen` tool. More on the generated stubs and utilities below.
 
 ## Man pages
 
@@ -26,21 +26,9 @@ The manpages are generated from the JSON schemas using the [`fromschema`](https:
 
 `msggen` is used to generate JSON-RPC client stubs, and converters between in-memory formats and the JSON format. In addition, by chaining some of these we can expose a [grpc](https://grpc.io/) interface that matches the JSON-RPC interface. This conversion chain is implemented in the [grpc-plugin](https://github.com/ElementsProject/lightning/tree/master/plugins/grpc-plugin).
 
-[block:image]
-{
-  "images": [
-    {
-      "image": [
-        "https://files.readme.io/8777cc4-image.png",
-        null,
-        null
-      ],
-      "align": "center",
-      "caption": "Artifacts generated from the JSON Schemas using `msggen`"
-    }
-  ]
-}
-[/block]
+![Artifacts generated from the JSON Schemas using `msggen`](https://files.readme.io/8777cc4-image.png)
+
+*Artifacts generated from the JSON Schemas using `msggen`*
 
 ### `cln-rpc`
 
@@ -58,4 +46,4 @@ The `cln-grpc` crate is mostly used to provide the primitives to build the `grpc
 - Next it generates the `convert.rs` file which is used to convert the structs for in-memory representation from `cln-rpc` into the corresponding protobuf structs.
 - Finally `msggen` generates the `server.rs` file which can be bound to a grpc endpoint listening for incoming grpc requests, and it will convert the request and forward it to the JSON-RPC. Upon receiving the response it gets converted back into a grpc response and sent back.
 
-![](https://files.readme.io/53b4645-image.png)
+![Conversion chain for grpc functionality](https://files.readme.io/53b4645-image.png)

doc/contribute-to-core-lightning/code-generation.md

@@ -14,10 +14,10 @@ To read the code, you should start from [lightningd.c](https://github.com/Elemen
 
 Here's a list of parts, with notes:
 
-- ccan - useful routines from <http://ccodearchive.net>
+- ccan - useful routines from http://ccodearchive.net
   - Use make update-ccan to update it.
   - Use make update-ccan CCAN_NEW="mod1 mod2..." to add modules
-  - Do not edit this!  If you want a wrapper, add one to common/utils.h.
+  - Do not edit this! If you want a wrapper, add one to common/utils.h.
 
 - bitcoin/ - bitcoin script, signature and transaction routines.
   - Not a complete set, but enough for our purposes.
@@ -69,18 +69,15 @@ Here's a list of parts, with notes:
 
 ## Database
 
-Core Lightning state is persisted in `lightning-dir`. It is a sqlite database stored in the `lightningd.sqlite3` file, typically under `~/.lightning/<network>/`.  
-You can run queries against this file like so:
+Core Lightning state is persisted in `lightning-dir`. It is a sqlite database stored in the `lightningd.sqlite3` file, typically under `~/.lightning/<network>/`.
 
+You can run queries against this file like so:
 ```shell
 $ sqlite3 ~/.lightning/bitcoin/lightningd.sqlite3 \
   "SELECT HEX(prev_out_tx), prev_out_index, status FROM outputs"
 ```
 
-
-
 Or you can launch into the sqlite3 repl and check things out from there:
-
 ```shell
 $ sqlite3 ~/.lightning/bitcoin/lightningd.sqlite3
 SQLite version 3.21.0 2017-10-24 18:55:49
@@ -93,16 +90,13 @@ sqlite> .schema outputs
 ...
 ```
 
-
-
 Some data is stored as raw bytes, use `HEX(column)` to pretty print these.
 
 Make sure that clightning is not running when you query the database, as some queries may lock the database and cause crashes.
 
 #### Common variables
 
 Table `vars` contains global variables used by lightning node.
-
 ```shell
 $ sqlite3 ~/.lightning/bitcoin/lightningd.sqlite3
 SQLite version 3.21.0 2017-10-24 18:55:49
@@ -115,55 +109,43 @@ bip32_max_index|4
 ...
 ```
 
-
-
 Variables:
 
 - `next_pay_index` next resolved invoice counter that will get assigned.
 - `bip32_max_index` last wallet derivation counter.
 
-Note: Each time `newaddr` command is called, `bip32_max_index` counter is increased to the last derivation index. Each address generated after `bip32_max_index` is not included as  
-lightning funds.
+Note: Each time `newaddr` command is called, `bip32_max_index` counter is increased to the last derivation index. Each address generated after `bip32_max_index` is not included as lightning funds.
 
 # gossip_store: Direct Access To Lightning Gossip
 
-The `lightning_gossipd` daemon stores the gossip messages, along with some internal data, in a file called the "gossip_store".  Various plugins and daemons access this (in a read-only manner), and the format is documented here.
+The `lightning_gossipd` daemon stores the gossip messages, along with some internal data, in a file called the "gossip_store". Various plugins and daemons access this (in a read-only manner), and the format is documented here.
 
 ## The File Header
-
 ```
 u8 version;
 ```
 
-
-
-The gossmap header consists of one byte.  The top 3 bits are the major version: if these are not all zero, you need to re-read this (updated) document to see what changed.  The lower 5 bits are the minor version, which won't worry you: currently they will be 11.
+The gossmap header consists of one byte. The top 3 bits are the major version: if these are not all zero, you need to re-read this (updated) document to see what changed. The lower 5 bits are the minor version, which won't worry you: currently they will be 11.
 
 After the file header comes a number of records.
 
 ## The Record Header
-
 ```
 be16 flags;
 be16 len;
 be32 crc;
 be32 timestamp;
 ```
 
-
-
-Each record consists of a header and a message.  The header is big-endian, containing flags, the length (of the following body), the crc32c (of the following message, starting with the timestamp field in the header) and a timestamp extracted from certain messages (zero where not relevant, but ignore it in those cases).
+Each record consists of a header and a message. The header is big-endian, containing flags, the length (of the following body), the crc32c (of the following message, starting with the timestamp field in the header) and a timestamp extracted from certain messages (zero where not relevant, but ignore it in those cases).
 
 The flags currently defined are:
-
 ```
 #define DELETED		 0x8000
 #define PUSH		 0x4000
 #define DYING		 0x0800
 ```
 
-
-
 Deleted fields should be ignored: on restart, they will be removed as the gossip_store is rewritten.
 
 The push flag indicates gossip which is generated locally: this is important for gossip timestamp filtering, where peers request gossip and we always send our own gossip messages even if the timestamp wasn't within their request.
@@ -174,15 +156,15 @@ Other flags should be ignored.
 
 ## The Message
 
-Each messages consists of a 16-bit big-endian "type" field (for efficiency, an implementation may read this along with the header), and optional data.  Some messages are defined by the BOLT 7 gossip protocol, others are for internal use.  Unknown message types should be skipped over.
+Each messages consists of a 16-bit big-endian "type" field (for efficiency, an implementation may read this along with the header), and optional data. Some messages are defined by the BOLT 7 gossip protocol, others are for internal use. Unknown message types should be skipped over.
 
 ### BOLT 7 Messages
 
 These are the messages which gossipd has validated, and ensured are in order.
 
-- `channel_announcement` (256): a complete, validated channel announcement.  This will always come before any `channel_update` which refers to it, or `node_announcement` which refers to a node.
-- `channel_update` (258): a complete, validated channel update.  Note that you can see multiple of these (old ones will be deleted as they are replaced though).
-- `node_announcement` (257): a complete, validated node announcement.  Note that you can also see multiple of these (old ones will be deleted as they are replaced).
+- `channel_announcement` (256): a complete, validated channel announcement. This will always come before any `channel_update` which refers to it, or `node_announcement` which refers to a node.
+- `channel_update` (258): a complete, validated channel update. Note that you can see multiple of these (old ones will be deleted as they are replaced though).
+- `node_announcement` (257): a complete, validated node announcement. Note that you can also see multiple of these (old ones will be deleted as they are replaced).
 
 ### Internal Gossip Daemon Messages
 
@@ -209,26 +191,26 @@ This contains a private `channel_update` (i.e. for a channel described by `gossi
 - `gossip_store_delete_chan` (4103)
   - `scid`: u64
 
-This is added when a channel is deleted.  You won't often see this if you're reading the file once (as the channel record header will have been marked `deleted` first), but useful if you are polling the file for updates.
+This is added when a channel is deleted. You won't often see this if you're reading the file once (as the channel record header will have been marked `deleted` first), but useful if you are polling the file for updates.
 
 - `gossip_store_ended` (4105)
   - `equivalent_offset`: u64
 
-This is only ever added as the final entry in the gossip_store.  It means the file has been deleted (usually because lightningd has been restarted), and you should re-open it.  As an optimization, the `equivalent_offset` in the new file reflects the point at which the new gossip_store is equivalent to this one (with deleted records removed).  However, if lightningd has been restarted multiple times it is possible that this offset is not valid, so it's really only useful if you're actively monitoring the file.
+This is only ever added as the final entry in the gossip_store. It means the file has been deleted (usually because lightningd has been restarted), and you should re-open it. As an optimization, the `equivalent_offset` in the new file reflects the point at which the new gossip_store is equivalent to this one (with deleted records removed). However, if lightningd has been restarted multiple times it is possible that this offset is not valid, so it's really only useful if you're actively monitoring the file.
 
 - `gossip_store_chan_dying` (4106)
   - `scid`: u64
   - `blockheight`: u32
 
-This is placed in the gossip_store file when a funding transaction is spent.  `blockheight` is set to 12 blocks beyond the block containing the spend: at this point, gossipd will delete the channel.
+This is placed in the gossip_store file when a funding transaction is spent. `blockheight` is set to 12 blocks beyond the block containing the spend: at this point, gossipd will delete the channel.
 
 ## Using the Gossip Store File
 
-- Always check the major version number!  We will increment it if the format changes in a way that breaks readers.
+- Always check the major version number! We will increment it if the format changes in a way that breaks readers.
 - Ignore unknown flags in the header.
 - Ignore message types you don't know.
 - You don't need to check the messages, as they have been validated.
-- It is possible to see a partially-written record at the end.  Ignore it.
+- It is possible to see a partially-written record at the end. Ignore it.
 
 If you are keeping the file open to watch for changes: