This really applies only to RaspiBlitz. Depending on the current
setup step there still isn't a Bitcoin Deamon or Lightning Node running.
We must defer the registration of all those handlers until later when
everything is properly setup.
Since there is a final reboot after the setup there is no need to
check in the background whether setup is finished. The API server
is restartet anyway.
refs #71
To keep Blitz API platform independent two code paths have been
implemented. A new "platform" .env variable must be set if running
on a raspiblitz to fetch hardware data from Redis. See the comments
in .env_sample for further explanation.
When someone connects to the SSE endpoint and the wallet is
locked a message with event name `wallet_lock_status` type is sent:
```js
// only sent when a new SSE connection is established and the wallet is
// locked at the same time
event: wallet_lock_status
data: {"locked": true}
```
When the wallet is unlocked either through SSH or the API, another
event is sent:
```js
// sent always when a new connection is established when the wallet
// is unlocked, or it is sent when the wallet was unlocked after
// connection was established
event: wallet_lock_status
data: {"locked": false}
```
It is always the first thing the client receives. After the unlock
event, the usual warmup data is sent.
refs #34
Bitcoin Core calculates the blockchain verification by including
unconfirmed transactions. This means that everytime there is
a new transaction, a `btc_info` event is fired through the SSE
channel. For clients this information is usually not useful beyond
two digits. Solution: round to two digits for SSE events.
The full floating point value can still be fetched through
`/bitcoin/get-blockhain-info`
closes#52
This is only useful for application running directly on the Raspiblitz.
This will create a file in ~/.blitz_api/.cookie with a valid JWT token.
Local applications can use this to authenticate to the API without
having to ask for the password. This is similar to how Bitcoin Cores
cookie auth works.
* new endpoint: /lightning/unlock-wallet
* ln endpoints return HTTP_423_LOCKED status if wallet is locked
* bootup sequence defers ln listeners setup if wallet is locked
refs #34
