v0.23.0: Overhauled pre-images API, new API for inter-nodes communication, block rewards fixed

Major improvements since v0.22.0:

Some sections of the configuration file are now properly validated

Previously, some nested sections were not adequately validated during config parsing,
which would lead to cryptic errors on startup.
Those sections are now properly validated and the resulting errors will be much more user-friendly.

The metadata.dat storage is obsolete

This file, stored alongside the cache and state DB, was used for network metadata.
It has been superseeded by the cache DB, and can now be completely removed,
all the relevant informations are new stored in their own table.

Flash: Private channels are now gossipped again

Since Agora's Flash path finding is source based, when a private channel
funder wants to receive a payment through their private channel,
the source would have to know about existence of the channel.

The initial implementation of private channels (in v0.22.0) did not gossip them,
leading to routing failures.

Flash: Channel updates are now signed externally

To completely remove the need to communicate one's private key to the node
for the Flash layer to work, the previously-available POST /change_fees
(FlashControlAPI.changeFees()) have been removed and its task now needs
to be performed by the wallet.

Pre-image GET endpoints have been overhauled

The following breaking changes have been made to the endpoints used to get pre-images:

• FullNode.getPreimages (GET /preimages) is now getPreimagesFrom (GET /preimages_from).
  The start_height parameter is still present, however end_height has been removed,
  and the endpoint will now return all known pre-images from that height.
• FullNode.getPreimagesForEnrollkey (GET /preimages_for_enroll_keys) is now getPreimages.
  The parameter and its semantic are unchanged.

Pre-image revelation is now configurable

In order to avoid slashing in the event of a minor downtimes, nodes reveal their pre-images
slightly in advance. Historically this has been fixed to 6 blocks, ensuring nodes can be
offline for up to an hour without being slashed (more if a watchtower is configured).
This value is now configurable under the setting validator.max_preimage_reveal.
It's default value is still set to 6.

Introduced flash node seed for uncollaborative close attempts

When an uncollaborative close is made and detected by a service provider (e.g. wallet operator),
previously-allocated fees might be insufficient.
In order to deal with this situation, a flash node seed has been introduced (flash.seed),
which ensures that closes can always be successful.

DNS registry now supports AXFR

AXFR requests are now supported by the name registry, allowing to transfer whole zones from
an authoritative server to a secondary one.

Nodes will now register themselves to the registry more eagerly

Instead of relying on a timer, nodes will now try to register to the name registry
as soon as they externalize a block with their enrollment.

Removed POST /register_listener endpoint

This HTTP-only endpoint, which wasn't used in production, has been removed,
as it also had no effect.

Block rewards have been corrected

Experimental support for block rewards, added in the previous release,
accidentally delayed rewards by one extra period (1 day) in some cases.
This has been fixed and rewards will now be placed in the right block.

The getBlocksFrom endpoint will now return up to 24 blocks

Up from the previous limit of 20. This limit is in place to prevent DoS attacks,
and may be lifted altogether in the future when sending stream of data without
loading them in memory is implemented.

Nodes will now longer reject Enrollments if they have the stake in their tx pool

Previously, nodes would only accept Enrollment once the matching stake (UTXO) had been externalized.
However, the consensus protocol allows both to be externalized in the same block,
so this was an unnecessary limitation.
Nodes will now correctly check their tx pool for a valid stake before rejecting an enrollment.

Added experimental binary-based communication protocol

Agora currently supports communicating with clients and other nodes alike using a REST interface.
This REST interface can be exposed through HTTP or HTTPS. Additionally, the interface can be bound
to any number of network interface, under any port, to allow for any server-side configuration.

While offering a client interface which is REST-based is convenient, as it allows easy integration
and development from JavaScript, using REST between nodes tend to be wasteful,
as there is a large overhead involved in the HTTP(s) layer and JSON serialization.

From this release, Agora supports a binary interface over TCP, which a client can reference
using the tcp:// scheme in its configuration, and a server can enable using a type: tcp
in its interfaces configuration array.

Ideally, nodes in the network should switch to communicate using this interface only,
and may expose a separate public REST interface.