Signed-off-by: Vivek Singh <vivek.singh@msystechnologies.com>

As a user of a community Chef distribution, I would like to be able to use knife
bootstrap without requiring the license check [1]. It's expected that that user
would not be installing a licensed version of Chef Infra Client, but instead a
community distribution.

This provides a similar feature as used in other places which makes it much
easier to disable the license check.

[1] https://gitlab.com/cinc-project/distribution/workstation/-/issues/3

Signed-off-by: Lance Albertson <lance@osuosl.org>

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

Force subclasses to use the `config` hash directly.

This should not affect any knife plugins shipping in chef-workstation
since the calls to config_value have already been removed from all of
those plugins.  The multiple-argument version of config_value was not
actually used anywhere in those plugins and the single value version
was removed and replaced with accessing the config hash.  Since that
was introduced sometime in 15.x when the bootstrap changes went in,
it is not expected that many external knife plugins have picked up
the usage of config_value.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

Warn during bootstrapping when using validation keys

We should highly encourage users to move to validatorless bootstrapping
 1) It's more secure
 2) It requires less admin work since there no validation key to pass
    around or rotate

This also provides an improved message helping the user to move off the
old keys and fixes some bad formatting where the 2nd line was indented
about 40 columns.

Signed-off-by: Tim Smith <tsmith@chef.io>

This makes it really clear that you're not using the right protocol when you're bootstrapping a Windows node:

```
❰tsmith❙~/dev/work/chef(git✱knife_password)❱✘≻ bundle exec knife bootstrap 172.16.1.233 -U ubuntu
Connecting to 172.16.1.233
```

becomes

```
❰tsmith❙~/dev/work/chef(git✱knife_password)❱✘≻ bundle exec knife bootstrap 172.16.1.233 -U ubuntu
Connecting to 172.16.1.233 using ssh
```

Signed-off-by: Tim Smith <tsmith@chef.io>

Signed-off-by: Pete Higgins <pete@peterhiggins.org>

Autocorrected with chefstyle after enabling that cop. It was very hard to read some complex autocorrected blocks w/o this.

Signed-off-by: Tim Smith <tsmith@chef.io>

We have issue that are caused by old code before merging of hash values
were done correctly.

The `config` hash correctly merges all options and should always be
used.

Knife plugins should never touch Chef::Config[:knife] values (either
reading or writing from them).

The `knife_config` should be converted to the `config` hash since it
directly accesses Chef::Config[:knife] values.

The `config_value()` helper should no longer be used.  Very clearly most
people started to use that when they should just use the config hash
directly.  That was intended to be used only when a knife cli option
was being renamed and the former configuration value needed to be
used as well.  It has been cargo culted around as the way to access
config values, and that should really stop.

The DataBagSecretOption mixin has been cleaned up so that the cli
options read+write only to the config[:cl_secret] and
config[:cl_secret_file] values.  The config file values go into
config[:secret] and config[:secret_file].  The fact that those are
the merged values in the `config` hash doesn't matter since only
the cli should be writing to the first two and only the config
file should be writing to the latter two.  I don't know why it was
made so complicated to begin with, but if there's some hidden
chef-11.early backcompat there, then chef-16 deliberately breaks that.

The use of `locate_config_value` helpers in all knife plugins is also
discouraged (but they all implement those themselves), just use the
config hash, which has the correct hash merge ordering.  All of those
need to be deleted.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>