chore: introduce nightly feature flag to provide error backtrace

[BugenZhao]

What changes are included in this PR?

In nightly toolchain, there's an unstable feature error_generic_member_access which allows accessing the error to extract additional information. A common convention is to provide error backtrace here.

This PR introduces a new non-default feature named nightly to iceberg crate. When it's enabled, we will provide the backtrace if it's captured in iceberg::Error.

Are these changes tested?

[liurenjie1024]

Hi, @BugenZhao IIRC, this will require unstable rust toolchain? If so, I don't think we should introduce this.

[Xuanwo]

Is it a good idea to expose fn backtrace() -> &Backtrace for you? Relying on nightly toolchain (even hide under a feature) can be a pain for us.

[BugenZhao]

I don't think this change imposes actual "requirement" on the nightly toolchain: it's completely optional and not enabled by default.

Additionally, gating code that requires unstable language features behind a feature named "nightly" is also a common practice in the community.

[Xuanwo]

Detecting nightly features is not recommended by the Rust community, as nightly features can be renamed or removed at any time.

For example: tkaitchuck/aHash#200

Fundamentally this is caused by logic in build.rs that auto-enables a nightly feature when it detects that it is built with a nightly rustc. Such logic is fragile and prone to errors as nightly features evolve before stabilization.

Crates should never automatically enable nightly features, this should generally be opt-in. If they try to do it automatically they need to be very careful and account for the fact that nightly features are not stable, and might look very different in future nightly versions.

I see aHash still does the same kind of auto-detection with the specialize feature. That's a similar issue just waiting to happen.

Similar things have happened many times before. We don't want to disrupt our users, especially those using the nightly version of rustc. I understand the motivation behind this change, but since we have already provided an alternative, perhaps we can wait until this feature is stabilized.

[BugenZhao]

Just to be clear: I'm also not introducing any sort of auto detection of feature here. It's totally opt-in, which is instead recommended according to your reference:

Crates should never automatically enable nightly features, this should generally be opt-in.

Also there are some discussions at https://users.rust-lang.org/t/is-it-suitable-to-require-nightly-in-public-crate/97768:

In that case maybe you could make the nightly features opt-in, by hiding them behind a feature gate in your crate. I.e. a feature nightly which users can enable if they want to use the macro that is more elegant.

The standard practice is to use a cargo feature which you ask nightly users to enable.