More compact encoding of the overlay schedule

[mrBliss]

While updating the golden test for LedgerState in ouroboros-consensus, which is basically NewEpochState + some extras, I noticed that the binary encoding of the overlay schedule (Map SlotNo (OBftSlot crypto) where data OBftSlot crypto = NonActiveSlot | ActiveSlot !(GenKeyHash crypto) is very repetitive:

TkMapLen 0
TkMapLen 50
TkInt 0
TkListLen 1
TkBytes "\SO\152\236\221"
TkInt 2
TkListLen 1
TkBytes "!Mlu"
TkInt 4
TkListLen 1
TkBytes "Sk\188V"
TkInt 6
TkListLen 1
TkBytes "r\198Y\SO"
TkInt 8
TkListLen 1
TkBytes "\135\151\&0\144"
TkInt 10
TkListLen 1
TkBytes "\195\232\167\212"
TkInt 12
TkListLen 1
TkBytes "\246\216G\149"
TkInt 14
TkListLen 1
TkBytes "\SO\152\236\221"
TkInt 16
TkListLen 1
TkBytes "!Mlu"
TkInt 18
TkListLen 1
TkBytes "Sk\188V"
TkInt 20
TkListLen 1
TkBytes "r\198Y\SO"
TkInt 22
TkListLen 1
TkBytes "\135\151\&0\144"
TkInt 24
TkListLen 1
TkBytes "\195\232\167\212"
TkInt 26
TkListLen 1
TkBytes "\246\216G\149"
TkInt 28
TkListLen 1
TkBytes "\SO\152\236\221"
TkInt 30
TkListLen 1
TkBytes "!Mlu"
TkInt 32
TkListLen 1
TkBytes "Sk\188V"
TkInt 34
TkListLen 1
TkBytes "r\198Y\SO"
TkInt 36
TkListLen 1
TkBytes "\135\151\&0\144"
TkInt 38
TkListLen 1
TkBytes "\195\232\167\212"
TkInt 40
TkListLen 1
TkBytes "\246\216G\149"
TkInt 42
TkListLen 1
TkBytes "\SO\152\236\221"
TkInt 44
TkListLen 1
TkBytes "!Mlu"
TkInt 46
TkListLen 1
TkBytes "Sk\188V"
TkInt 48
TkListLen 1
TkBytes "r\198Y\SO"
TkInt 50
TkListLen 1
TkBytes "\135\151\&0\144"
TkInt 52
TkListLen 1
TkBytes "\195\232\167\212"
TkInt 54
TkListLen 1
TkBytes "\246\216G\149"
TkInt 56
TkListLen 1
TkBytes "\SO\152\236\221"
TkInt 58
TkListLen 1
TkBytes "!Mlu"
TkInt 60
TkListLen 1
TkBytes "Sk\188V"
TkInt 62
TkListLen 1
TkBytes "r\198Y\SO"
TkInt 64
TkListLen 1
TkBytes "\135\151\&0\144"
TkInt 66
TkListLen 1
TkBytes "\195\232\167\212"
TkInt 68
TkListLen 1
TkBytes "\246\216G\149"
TkInt 70
TkListLen 1
TkBytes "\SO\152\236\221"
TkInt 72
TkListLen 1
TkBytes "!Mlu"
TkInt 74
TkListLen 1
TkBytes "Sk\188V"
TkInt 76
TkListLen 1
TkBytes "r\198Y\SO"
TkInt 78
TkListLen 1
TkBytes "\135\151\&0\144"
TkInt 80
TkListLen 1
TkBytes "\195\232\167\212"
TkInt 82
TkListLen 1
TkBytes "\246\216G\149"
TkInt 84
TkListLen 1
TkBytes "\SO\152\236\221"
TkInt 86
TkListLen 1
TkBytes "!Mlu"
TkInt 88
TkListLen 1
TkBytes "Sk\188V"
TkInt 90
TkListLen 1
TkBytes "r\198Y\SO"
TkInt 92
TkListLen 1
TkBytes "\135\151\&0\144"
TkInt 94
TkListLen 1
TkBytes "\195\232\167\212"
TkInt 96
TkListLen 1
TkBytes "\246\216G\149"
TkInt 98
TkListLen 1
TkBytes "\SO\152\236\221"

For each slot in the overlay schedule, which, if I'm not mistaken, is the number of slots in the epoch = 21600, it will contain either an empty element (NonActiveSlot) or a hash (ActiveSlot !(GenKeyHash crypto)).

The binary encoding is wasteful as the same 7 (= number of core nodes) hashes end up many, many times in the encoding.

We can optimise this by converting the Map SlotNo (OBftSlot crypto) type to the following representation before/after en/decoding:

Map (OBftSlot crypto) (NonEmpty SlotNo)

Now each hash will only be stored exactly once.

P.S. using Map SlotNo (OBftSlot crypto) as the in-memory representation is less bad, because the hashes should be shared (which would be the case after deserialising the above encoding, but not after deserialising the current one!). Nevertheless, I would be inclined to optimise this too.