Update Rust crate chrono to 0.4.30 (#362)

[![Mend
Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com)

This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [chrono](https://togithub.com/chronotope/chrono) | dependencies |
patch | `0.4.29` -> `0.4.30` |

---

### Release Notes

<details>
<summary>chronotope/chrono (chrono)</summary>

###
[`v0.4.30`](https://togithub.com/chronotope/chrono/releases/tag/v0.4.30):
0.4.30

[Compare
Source](https://togithub.com/chronotope/chrono/compare/v0.4.29...v0.4.30)

In this release, we have decided to swap out the `chrono::Duration` type
(which has been a re-export of time 0.1 `Duration` type) with our own
definition, which exposes a strict superset of the `time::Duration` API.
This helps avoid warnings about the [CVE-2020-26235] and
[RUSTSEC-2020-0071] advisories for downstream users and allows us to
improve the `Duration` API going forward.

While this is technically a SemVer-breaking change, we expect the risk
of downstream users experiencing actual incompatibility to be
exceedingly limited (see [our
analysis](https://togithub.com/chronotope/chrono/pull/1095#issuecomment-1571716955)
of public code using a crater-like experiment), and not enough
justification for the large ecosystem churn of a 0.5 release. If you
have any feedback on these changes, please let us know in
[#&#8203;1268](https://togithub.com/chronotope/chrono/issues/1268).

##### Additions

- Add `NaiveDate::leap_year`
([#&#8203;1261](https://togithub.com/chronotope/chrono/issues/1261))

##### Documentation

- Update main documentation from README
([#&#8203;1260](https://togithub.com/chronotope/chrono/issues/1260),
thanks [@&#8203;Stygmates](https://togithub.com/Stygmates))
- Add history of relation between chrono and time 0.1 to documentation
([chronotope/chrono#1264,
[chronotope/chrono#1266)
- Clarify `Timelike::num_seconds_from_midnight` is a simple mapping
([#&#8203;1255](https://togithub.com/chronotope/chrono/issues/1255))

#### Relation between chrono and time 0.1

Rust first had a `time` module added to `std` in its 0.7 release. It
later moved to `libextra`, and then to a `libtime` library shipped
alongside the standard library. In 2014 work on chrono started in order
to provide a full-featured date and time library in Rust. Some
improvements from chrono made it into the standard library; notably,
`chrono::Duration` was included as `std::time::Duration` ([rust#15934])
in 2014.

In preparation of Rust 1.0 at the end of 2014 `libtime` was moved out of
the Rust distro and into the `time` crate to eventually be redesigned
([rust#18832], [rust#18858]), like the `num` and `rand` crates. Of
course chrono kept its dependency on this `time` crate. `time` started
re-exporting `std::time::Duration` during this period. Later, the
standard library was changed to have a more limited unsigned `Duration`
type ([rust#24920], [RFC 1040]), while the `time` crate kept the full
functionality with `time::Duration`. `time::Duration` had been a part of
chrono's public API.

By 2016 `time` 0.1 lived under the `rust-lang-deprecated` organisation
and was not actively maintained ([time#136]). chrono absorbed the
platform functionality and `Duration` type of the `time` crate in
[chrono#478] (the work started in [chrono#286]). In order to preserve
compatibility with downstream crates depending on `time` and `chrono`
sharing a `Duration` type, chrono kept depending on time 0.1. chrono
offered the option to opt out of the `time` dependency by disabling the
`oldtime` feature (swapping it out for an effectively similar chrono
type). In 2019, [@&#8203;jhpratt](https://togithub.com/jhpratt) took
over maintenance on the `time` crate and released what amounts to a new
crate as `time` 0.2.

[rust#15934]: https://togithub.com/rust-lang/rust/pull/15934

[rust#18832]:
https://togithub.com/rust-lang/rust/pull/18832#issuecomment-62448221

[rust#18858]: https://togithub.com/rust-lang/rust/pull/18858

[rust#24920]: https://togithub.com/rust-lang/rust/pull/24920

[RFC 1040]: https://rust-lang.github.io/rfcs/1040-duration-reform.html

[time#136]: https://togithub.com/time-rs/time/issues/136

[chrono#286]: https://togithub.com/chronotope/chrono/pull/286

[chrono#478]: https://togithub.com/chronotope/chrono/pull/478

##### Security advisories

In November of 2020 [CVE-2020-26235] and [RUSTSEC-2020-0071] were opened
against the `time` crate.
[@&#8203;quininer](https://togithub.com/quininer) had found that calls
to `localtime_r` may be unsound ([chrono#499]). Eventually, almost a
year later, this was also made into a security advisory against chrono
as [RUSTSEC-2020-0159], which had platform code similar to `time`.

On Unix-like systems a process is given a timezone id or description via
the `TZ` environment variable. We need this timezone data to calculate
the current local time from a value that is in UTC, such as the time
from the system clock. `time` 0.1 and chrono used the POSIX function
`localtime_r` to do the conversion to local time, which reads the `TZ`
variable.

Rust assumes the environment to be writable and uses locks to access it
from multiple threads. Some other programming languages and libraries
use similar locking strategies, but these are typically not shared
across languages. More importantly, POSIX declares modifying the
environment in a multi-threaded process as unsafe, and `getenv` in libc
can't be changed to take a lock because it returns a pointer to the data
(see [rust#27970] for more discussion).

Since version 4.20 chrono no longer uses `localtime_r`, instead using
Rust code to query the timezone (from the `TZ` variable or via
`iana-time-zone` as a fallback) and work with data from the system
timezone database directly. The code for this was forked from the [tz-rs
crate] by [@&#8203;x-hgg-x](https://togithub.com/x-hgg-x). As such,
chrono now respects the Rust lock when reading the `TZ` environment
variable. In general, code should avoid modifying the environment.

[CVE-2020-26235]: https://nvd.nist.gov/vuln/detail/CVE-2020-26235

[RUSTSEC-2020-0071]: https://rustsec.org/advisories/RUSTSEC-2020-0071

[chrono#499]: https://togithub.com/chronotope/chrono/pull/499

[RUSTSEC-2020-0159]:
https://rustsec.org/advisories/RUSTSEC-2020-0159.html

[rust#27970]: https://togithub.com/rust-lang/rust/issues/27970

[chrono#677]: https://togithub.com/chronotope/chrono/pull/677

[tz-rs crate]: https://crates.io/crates/tz-rs

##### Removing time 0.1

Because time 0.1 has been unmaintained for years, however, the security
advisory mentioned above has not been addressed. While chrono
maintainers were careful not to break backwards compatibility with the
`time::Duration` type, there has been a long stream of issues from users
inquiring about the time 0.1 dependency with the vulnerability. We
investigated the potential breakage of removing the time 0.1 dependency
in [chrono#1095] using a crater-like experiment and determined that the
potential for breaking (public) dependencies is very low. We reached out
to those few crates that did still depend on compatibility with time
0.1.

As such, for chrono 0.4.30 we have decided to swap out the time 0.1
`Duration` implementation for a local one that will offer a strict
superset of the existing API going forward. This will prevent most
downstream users from being affected by the security vulnerability in
time 0.1 while minimizing the ecosystem impact of semver-incompatible
version churn.

[chrono#1095]: https://togithub.com/chronotope/chrono/pull/1095

Thanks to all contributors on behalf of the chrono team,
[@&#8203;djc](https://togithub.com/djc) and
[@&#8203;pitdicker](https://togithub.com/pitdicker)!

</details>

---

### Configuration

📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).

🚦 **Automerge**: Enabled.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.

---

- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box

---

This PR has been generated by [Mend
Renovate](https://www.mend.io/free-developer-tools/renovate/). View
repository job log
[here](https://developer.mend.io/github/ziyadedher/evm-bench).

<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNi44My4wIiwidXBkYXRlZEluVmVyIjoiMzYuODMuMCIsInRhcmdldEJyYW5jaCI6Im1haW4ifQ==-->

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Cargo.toml

@@ -13,7 +13,7 @@ keywords = ["benchmark", "ethereum", "smart-contracts", "ethereum-contract", "be
 
 [dependencies]
 bytes = "1.5.0"
-chrono = "0.4.29"
+chrono = "0.4.30"
 clap = { version = "4.4.2", features = ["derive"] }
 env_logger = "0.10.0"
 glob = "0.3.1"