Feature graph support for Cargo tree

Problem

I have a large dependency tree and want to figure out why a transitive dependency is included, which is optional based on features. I had assumed that is what cargo tree -e features is for, but apparently that is not quite what it does. See this related discussion.

To give a brief summary: I use the datafusion crate, which depends on many datafusion-* crates. Many of these datafusion-* crates depend on the parquet crate. Some of them depend on the feature parquet/encryption, which causes parquet to depend on ring. The tree shows that datafusion-common depends on parquet, which in turn depend on ring. However, datafusion-common does not enable the parquet/encryption feature. So, the tree suggests that ring is included as a result of using datafusion-common. It is actually enabled because of datafusion-datasource, which enables parquet/encryption. In the tree, ring does not show up as a child of datafusion-datasource (I do not know why).

The full tree is here.

Proposed Solution

I think there should be an option to output a feature dependency tree (or probably DAG). In this graph, the nodes would be either features of crates or crates themselves (with no default features enabled). The edges would be either:

• from feature A/a to feature B/b if feature a of crate A depends on feature b of its dependency crate B
• from feature A/a to crate B if A optionally depends on B for its a feature
• from crate A to feature B/b if A non-optionally depends on B/b
• from create A to crate B if A non-optionally dependends on B
• from feature A/a to feature A/b of the same feature depends on another feature of the same crate.

I am unsure if all features A/a should also have a dependency on the crate A itself, or if that is unnecessary noise.

This is actually the output format I would have expected from cargo tree -e features. I don't know if changing it to this new format now would be a good idea, so I filed this as a feature request rather than a bug report.

Notes

I think some of the confusion in #14263 may be related to this, but I did not look into that issue too closely.

Start by reproducing the datafusion/parquet/ring case with cargo tree -e features, then read the linked discussion and related issue #14263. Define the feature and crate nodes and dependency edges before changing the output; done means the graph accurately attributes enabled features and dependencies without misleading parent relationships.