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

Signed-off-by: rishichawda <rishichawda@users.noreply.github.com>

Signed-off-by: Thomas Heinen <theinen@tecracer.de>

Signed-off-by: Thomas Heinen <theinen@tecracer.de>

Signed-off-by: Thomas Heinen <theinen@tecracer.de>

Vault secrets are stored as key-value pairs, so the return value
from a secret lookup is always a Hash.

Example:

```
file "/home/user/test1" do
  content secret(name: "secret/example",
                 service: :hashi_vault,
                 config: {
                   vault_addr: "vault.example.com",
                   role_name: "example-role"
                 })[:answer]
end
```
As shown above, we are expecting a hash from Vault, and are populating the file
content based on the value of `:answer` in that hash.

Limitations:

* This iteration only supports instance authentication via a Vault
role connected to an IAM profile.
* This iteration does not support versioned secrets

Signed-off-by: Marc A. Paradise <marc.paradise@gmail.com>

In a recipe, usage will look like the following:
  value = secret(name: "test1", service: :aws_secrets_manager, config: { region: "us-west-1" })
  log "My secret is #{value.secret_string}"

Note the use of `secret_string` to determine the secret value. The
returned object here is Aws::Types::GetSecretValueResponse from the AWS SDK.

This beta implementation supports ec2/imds instance profile
authentication but also checks standard locations for credentials
configuration -- see documentation [1] for a description of default credentials search behavior.

[1] https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/SecretsManager/Client.html#initialize-instance_method

Signed-off-by: Marc A. Paradise <marc.paradise@gmail.com>

This should help us slim the size of the install down and it should also greatly speed up testing anything that deps directly on chef.

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

These are no longer required because knife files
will no longer be matched by the given pattern.

Signed-off-by: Marc A. Paradise <marc.paradise@gmail.com>

This moves knife into /knife, in the same way that chef-utils and
chef-config are separated.

NOTES:

== File History ==

If you see this message as the first message in the history of
an knife file, you can see the complete history by using
'git log --follow',  'git config log.follow true'  to make it the default
behavior in this repository, or 'git config --globa log.follow true' to
make it the global default.

== API Changes ==

At the API level, there is one breaking change:
CookbookSiteStreamingUploader has been moved out of chef and into
knife/core.

There were a combination of reasons we chose this path:
- CookbookSiteStreamingUploader (CSSU) is only used within Knife.
- CookbookSiteStreamingUploader (CSSU) references the
  command Chef::Knife::CookbookMetadata in order to generate
  a metadata file for the cookbook to upload
- Chef::Knife::CookbookMetadata is no longer available to Chef:: because
  Knife has been moved to its own gem.  Knife gem depends on the Chef gem,
  so Chef can't depend on something in Knife.

A search for usage in related projects (berks, chef-cli) and the
Internet at large shows that there are no known external consumers of CSSU.

For now, we'll move this class into Knife::Core, as it's going to be
faster than splitting off the metadata generation and time is a concern. If we
find that we need the metadata generation in chef/ proper, we should evaluate
decoupling that functionality from Knife::CookbookMetadata and exposing
it via something like `Chef::Cookbook::Metadata#from_cookbook_files`

== spec changes ==

The specs are kept in their existing locations, though we have
separated out a `knife_spec_helper` so that we can ensure knife is not
directly accessing chef requires; and chef is relying on knife's at all.

We also now clear gem paths with each test, to force gem state to reset.
This works around a problem where a combination of tests
is corrupting the internal Gem state, causing failures in
rubygems_spec.  See branch `mp/broken-gems` for many more details around
findings so far.

Signed-off-by: Marc A. Paradise <marc.paradise@gmail.com>