In `Slot end`, sync duties are reported one slot too late,
because sync committee duties are determined by the next slot
instead of the current one. Address that by taking account of this.
* Add metadata for the Holesky network
* Add copyright banner to the new Nim module
* Working version
* Bump Chronos to fix downloading from Github
* Add checksum check of the downloaded file
* Clean up debugging code and obsolete imports
* optimize epoch transition via get_flag_index_deltas() and get_inactivity_penalty_deltas()
* directly mutate Altair info in {get,update}_flag_and_inactivity_deltas
When bumping to a more recent commit than the configured `branch`,
currently the lint error message is confusing:
```
fatal: error processing shallow info: 4
Submodule 'vendor/nim-chronos': Failed to fetch 'master':
```
This happens when the selected commit is more recent than the latest
one on the `branch`. Comparing the commit dates allows a better message.
The `is_next_sync_committee_known` helper allocates a fresh
`SyncCommittee` in the caller and `nimZeroMem`s it on each use.
Use `static` to compare against a compile-time zeroed copy instead.
This also should help reduce stack size far enough to link with Nim 2.0.
The CI signing node sometimes becomes overloaded, leading to late block.
```
{"lvl":"DBG","ts":"2023-09-05 23:46:34.515+01:00","msg":"REST request body has been sent","remote":"127.0.0.1:5201","request":"/api/v1/eth2/sign/0x82ad1b336ce728978983cbe7c7dd25f757fdc66536f3457cf9f0120c07943f8d464eec55fefcaef9c0d5da6e9f7c1443","size":549,"http_method":"POST"}
```
```
DBG 2023-09-05 23:46:36.098+01:00 Received request peer=127.0.0.1:51194 meth=POST uri=/api/v1/eth2/sign/0x82ad1b336ce728978983cbe7c7dd25f757fdc66536f3457cf9f0120c07943f8d464eec55fefcaef9c0d5da6e9f7c1443
```
Especially on the `minimal` preset with short slot timings, this leads
to attestations and sync duties being made for an old head, ultimately:
```
{"lvl":"FAT","ts":"2023-09-05 23:46:41.915+01:00","msg":"Low sync committee participation","topics":"chaindag","slot":15,"num_active_participants":8}
```
Looking at `nimbus_signing_node.0.jsonl` shows that the signing node is
very busy. Lowering the validator count should reduce the latency a bit.
In Nim 2.0, the `test_fixture_operations` files fail to compile with:
```
Error: 'result' is of type <Result[system.void, system.cstring]> which cannot be captured as it would violate memory safety, declared here: /nimbus-eth2/tests/consensus_spec/bellatrix/test_fixture_operations.nim(130, 5); using '-d:nimNoLentIterators' helps in some cases. Consider using a <ref Result[system.void, system.cstring]> which can be captured.
```
Wrapping the `applyExecutionPayload` in a factory that takes `path`
avoids this problem.
Nim 2.0 gets confused when compiling `all_tests`:
```
Error: undeclared identifier: 'maxLen'
candidates (edit distance, scope distance); see '--spellSuggest':
(3, 7): 'Table'
(3, 7): 'len'
(3, 7): 'max'
```
Renaming the generic parameter `U` to `maxLen` fixes this somehow.
It also increases readability to use the same name consistently.
In Nim 2.0, attempting to use `Taskpool.spawn` inside `{.async.}` `proc`
leads to `Error: cannot generate destructor for generic type: Isolated`.
Add an intermediate wrapper `proc` that performs the `spawn` operation
to workaround the problem.
Suite names were not being used because `test` has to have access to it
during instantiation - this PR cleans things up a little while at the
same time upgrading unittest2.
