Cardano Updates

Changelog year typo

Changelog year typo

Changelog year typo

[ETCM-556] Add a metric for the total time it takes for FastSync to complete and update docker-compose Grafana dashboard

2468: Replace `hardfork_at` with `eras` object, and add node_era r=Anviking a=Anviking

# Issue Number

ADP-676


# Overview

<!-- Detail in a few bullet points the work accomplished in this PR -->

- [x] Replace `hardfork_at` with info of all eras
- [x] Instead of storing ProtocolParameters in DB, just keep them in a `TVar`
- [ ] <s>See if we can order the eras correctly in the `era` object (for when the JSON is viewed by humans)</s> Seems impossible to do.
- [x] TODO: Extend swagger
- [ ] Tiny doc tweaks

# Comments

- Could add absolute `slot` field also
- Arguably a bit sad that the eras get sorted seemingly alphabetically in the json

```json
$ cardano-wallet network parameters
{
    "slot_length": {
        "quantity": 1,
        "unit": "second"
    },
    "decentralization_level": {
        "quantity": 74,
        "unit": "percent"
    },
    "genesis_block_hash": "5f20df933584822601f9e3f8c024eb5eb252fe8cefb24d1317dc3d432e940ebb",
    "blockchain_start_time": "2017-09-23T21:44:51Z",
    "desired_pool_number": 500,
    "epoch_length": {
        "quantity": 432000,
        "unit": "slot"
    },
    "eras": {
        "shelley": {
            "epoch_start_time": "2020-07-29T21:44:51Z",
            "epoch_number": 208
        },
        "mary": null,
        "byron": {
            "epoch_start_time": "2017-09-23T21:44:51Z",
            "epoch_number": 0
        },
        "allegra": {
            "epoch_start_time": "2020-12-16T21:44:51Z",
            "epoch_number": 236
        }
    },
    "active_slot_coefficient": {
        "quantity": 5,
        "unit": "percent"
    },
    "security_parameter": {
        "quantity": 2160,
        "unit": "block"
    },
    "minimum_utxo_value": {
        "quantity": 1000000,
        "unit": "lovelace"
    }
}
```

<!-- Additional comments or screenshots to attach if any -->

<!--
Don't forget to:

 ✓ Self-review your changes to make sure nothing unexpected slipped through
 ✓ Assign yourself to the PR
 ✓ Assign one or several reviewer(s)
 ✓ Jira will detect and link to this PR once created, but you can also link this PR in the description of the corresponding ticket
 ✓ Acknowledge any changes required to the Wiki
 ✓ Finally, in the PR description delete any empty sections and all text commented in <!--, so that this text does not appear in merge commit messages.
-->


Co-authored-by: Johannes Lund <[email protected]>

Signed-off-by: xdzurman <[email protected]>

Refactoring of versions functionality

2471: Fix flaky `validateGenerators` r=KtorZ a=KtorZ

# Issue Number

<!-- Put here a reference to the issue that this PR relates to and which requirements it tackles. Jira issues of the form ADP- will be auto-linked. -->

#2393 

# Overview

<!-- Detail in a few bullet points the work accomplished in this PR -->

- deb387a4f0389e035a3feebdbb5610361cc751c3
  :round_pushpin: **rework 'validateGenerators' for the db arbitrary instance to be more reliable**
    And also give more information on failure. This should reduce the flakyness and provide more metrics on failure.

- 977078cc5881770612dc217fed6e8d594df67771
  :round_pushpin: **rework shrinkers on PolicyId, AssetName and TxId to be more aggressive**
    There's really nothing simpler between 'TokenB' compared to 'TokenC', or between '1111111111111111111111111' compared to '22222222222222222222222'

  The goal of a shrinker is to provide smaller counter examples, if shrinking a value doesn't make it smaller, the shrinker is pointless. In this very case, the shrinkers are actually sucking of CPU time for nothing as noted by the 'validateGenerators' property sometimes failing to shrink large data structures in a reasonable time.

  However, allowing values to shrink down to one common denominator help to make a counter example more readable by reducing the amount of noise in an output. That is, it's easier if all values of a particular types are the same. Thus, this commit changes shrinkers to reach that common denominator much more aggressively (in one step).

# Comments

<!-- Additional comments or screenshots to attach if any -->

Occurred quite often lately, so I thought I'd give it a shot. 

<!--
Don't forget to:

 ✓ Self-review your changes to make sure nothing unexpected slipped through
 ✓ Assign yourself to the PR
 ✓ Assign one or several reviewer(s)
 ✓ Jira will detect and link to this PR once created, but you can also link this PR in the description of the corresponding ticket
 ✓ Acknowledge any changes required to the Wiki
 ✓ Finally, in the PR description delete any empty sections and all text commented in <!--, so that this text does not appear in merge commit messages.
-->


Co-authored-by: KtorZ <[email protected]>

Co-authored-by: Jonathan Knowles <[email protected]>

Co-authored-by: Jonathan Knowles <[email protected]>

Co-authored-by: Jonathan Knowles <[email protected]>

Co-authored-by: Jonathan Knowles <[email protected]>

Co-authored-by: Jonathan Knowles <[email protected]>

Co-authored-by: Jonathan Knowles <[email protected]>