v0.4.21 patch upgrade breaks SGX builds

[nhynes]

chrono v0.4.21 introduces a new default feature clock which transitively pulls in iana-time-zone, which doesn't build on SGX. This PATCH version upgrade has caused a sever-incompatible change on the SGX target (and others for which iana-time-zone doesn't work).

I would suggest:

1. yanking v0.4.21
2. publishing v0.5.0 with the new feature+transitive dep

Until then, essentially all users of the SGX target via core crates such as mbedtls will need to carefully manage lockfiles, which isn't super fun.

https://github.com/chronotope/chrono/pull/767 thankfully fixes the problem. Hopefully the new patch version gets through okay.

[rdeaton]

This release also introduces a cyclic dependency. The following in Cargo.toml is sufficient to reproduce:

[dependencies]
core-foundation = { version = "0.9", features = ["with-chrono"] }

error: cyclic package dependency: package `chrono v0.4.21` depends on itself. Cycle:
package `chrono v0.4.21`
    ... which satisfies dependency `chrono = "^0.4"` of package `core-foundation v0.9.3`
    ... which satisfies dependency `core-foundation = "^0.9"` of package `iana-time-zone v0.1.42`
    ... which satisfies dependency `iana-time-zone = "^0.1.41"` of package `chrono v0.4.21

[esheppa]

Thanks for the report @nhynes and @rdeaton - and apologies for the breakage. It looks like we have a few options here:

• To avoid the cyclic dependency we could temporarily turn off iana-time-zone for macOS/iOS (at least until https://github.com/strawlab/iana-time-zone/pull/50 is merged)
• Yanking v0.4.21 sounds like a good idea to me, but potentially we could release the fixes as v0.4.22 - essentially the reason for yanking would be the semver incompatibility
• In the specific case of mbedtls it doesn't look like this is using Local, and in fact, it looks like the usage of chrono could be replaced by SystemTime looks like I spoke too soon, however clock can be disabled

[djc]

Sorry for the regression!

It seems like 0.4.20 would also be broken on SGX, and I don't think we're going to yank both -- and I'm guessing the audience for whom 0.4.21 improves things is much larger than the audience for whom it makes things worse. In this case I think we should just get a 0.4.22 out as soon as possible.

[pitdicker]

We are now at 0.4.26, this can be closed?