packer init doc clarification (#10558)

* Packer has no state like Terraform has

* init command docs: tell where a plugin will be installed

* docs: add a note that packer init does not work with legacy JSON templates

* docs: add a not that packer init does not install single-plugin binaries

* the plugin getter => packer init

* Update init.mdx

* grammar

* link to how to install plugins manually

* Update website/content/docs/commands/init.mdx

Co-authored-by: Sylvia Moss <moss@hashicorp.com>

* Update website/content/docs/commands/init.mdx

Co-authored-by: Sylvia Moss <moss@hashicorp.com>

Co-authored-by: Sylvia Moss <moss@hashicorp.com>

website/content/docs/commands/init.mdx

@@ -7,13 +7,14 @@ sidebar_title: <tt>init</tt>
 
 # `init` Command
 
--> **Note:** Packer does not currently have the notion of a state.
+-> **Note:** Packer does not currently have the notion of a state like Terraform
+has. In other words, currently `packer init` is only in charge of installing
+packer plugins.
 
-
--> **Note:** Currently, the plugin getter can only fetch binaries from public
+-> **Note:** Currently, `packer init` can only fetch binaries from public
 projects on *Github*.
 
--> **Note:** Currently, the plugin getter only fetches binaries using Github's
+-> **Note:** Currently, `packer init` only fetches binaries using Github's
 public API, which [limits the number of unauthenticated requests per hour one IP
 can
 do](https://docs.github.com/en/developers/apps/rate-limits-for-github-apps#normal-user-to-server-rate-limits).
@@ -23,6 +24,13 @@ usage this should not be an issue. Otherwise you can set the
 your personal [access token page](https://github.com/settings/tokens) to
 generate a new token.
 
+-> **Note:** Packer init does not work with legacy JSON templates. You can
+upgrade your JSON config files to HCL using the hcl2ugprade command.
+
+-> **Note:** Packer init will only work with multiplugins -- that is plugins
+that are named `packer-plugin-*` -- to install a single plugin binary -- that is
+`packer-provisioner-*`, `packer-builder-*`, etc. -- nothing changes, you will
+have to [install the plugin manually](/docs/plugins#installing-plugins).
 
 The `packer init` command is used to download Packer plugin binaries.
 This is the first command that should be executed when working with a new or
@@ -51,8 +59,11 @@ packer {
 ```
 
 Packer init will install the latest found version matching the version selection
-in the `required_plugins` section. Make sure to set a correct [version constraint
-string](/docs/templates/hcl_templates/blocks/packer#version-constraints).
+in the `required_plugins` section. Make sure to set a correct [version
+constraint
+string](/docs/templates/hcl_templates/blocks/packer#version-constraints). The
+plugins will be installed in the [Plugin
+Directory](/docs/configure#packer-s-plugin-directory).
 
 
 ## Options

website/content/docs/plugins/index.mdx

@@ -40,9 +40,10 @@ communicates with them. For example, the Shell provisioner is actually run as
 look at your process list and you should see a handful of `packer-` prefixed
 applications running.
 
+## Installing Plugins
 
 <Tabs>
-<Tab heading="Plugins installed with Packer init (from Packer v1.7.0)">
+<Tab heading="with Packer init (from Packer v1.7.0)">
 
 ~> **Note**: Only _multi-plugin binaries_ -- that is plugins named
 packer-plugin-*, like the `packer-plugin-amazon` -- are expected to work with
@@ -152,7 +153,7 @@ Packer will error if you set the `packer-plugin-` prefix in a `source`. This
 will avoid conflicting with other plugins for other tools, like Terraform.
 
 </Tab>
-<Tab heading="Manually installed legacy plugins">
+<Tab heading="manually">
 
 The easiest way to manually install a plugin is to name it correctly, then place
 it in the proper directory. To name a plugin correctly, make sure the binary is