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>

Mostly this is all fixes necessary for ruby 3.0

There's the addition of the appbundle hook which lets us better pull
git gems into appbundler

Note carefully how after adding the post-bundle-install.rb that
trying to pre appbundle-update ohai pulls in chef/chef as bundle
installed git gem which fails to install so we go back to only
using one appbundle-update on chef/chef and removing the chef/ohai
one (which may fix other bugs).

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