Migrate cli implementation from clap to structopt

[sajjaphani]

#7866

Removes the clap parsing logic and implements the struct opt cli implementations.

[sajjaphani]

Removed all the clap_app macro invocations of clap and converted the options into structopt structures. The remaining work related to consuming the Structure returned by structopt will be taken into a separate PR.

[christophermaier]

A few changes to make, but overall this looks good! I think with this we can remove the feature flag for a structopt CLI, since that's now the only choice.

[christophermaier]

Spelling error on OritinKeyExport

[christophermaier]

Is this not the same as Hab::clap() above?

[sajjaphani]

Yup, here is the updated code.

pub fn get(feature_flags: FeatureFlag) -> App<'static, 'static> {
    if feature_flags.contains(FeatureFlag::STRUCTOPT_CLI) {
        return Hab::clap();
    }

    Options::clap()
}

[christophermaier]

Originally, when we were first rolling out structopt to represent parts of the CLI, we hid it behind a feature flag so users could opt in and give feedback, but if anything went wrong, there was an "escape hatch".

Now, however, the CLI is only going to be implemented using structopt. In that case, it seems that Hab::clap() and Options::clap() are going to be the same. Thus, Options is basically a duplicate of Hab, which means we don't need Options at all. It furthermore implies that we can remove the STRUCTOPT_CLI feature flag altogether.

Are there meaningful differences between Hab and Options, or can the latter be removed?

[sajjaphani]

I see some aliases are being explicitly set on certain subcommands, which are not present in Hab::clap() part, and also see some settings are being set settings = &[AppSettings::ArgRequiredElseHelp, AppSettings::SubcommandRequiredElseHelp]

[christophermaier]

I have one comment, but otherwise I think this looks good. Thanks for tackling this!

[christophermaier]

While I generally dislike * imports as a rule, I think it could be helpful for the use statements that we've got in this corner of the code, simply because of the sheer volume of imports, as well as the fact that many of those imports are auto-generated ConfigOpt ones, which tends to make things look a bit confusing.

So, this highlighted code could be collapsed to use self::bldr::*, with similar replacements for the other module declarations, both in this file and in others that this PR is touching.

What do you think?

[sajjaphani]

Agree in this case!