Add controller-led worker auth flow (#2413)

This adds an action to the API that allows pulling out an activation
token that can be given to a worker in its config (directly or via env
or file). The worker can pass this along with its normal request in
place of its normal nonce and the server will automatically accept it.

Co-authored-by: Irena Rindos <irenarindos@users.noreply.github.com>

website/content/docs/concepts/security/permissions/resource-table.mdx

@@ -1472,6 +1472,17 @@ documentation](https://www.boundaryproject.io/api-docs) for guidance.
               <code>type=&lt;type&gt;;actions=list</code>
             </li>
           </ul>
+          <li>
+            <code>create:controller-led</code>: Create a worker using the controller-led workflow
+          </li>
+          <ul>
+            <li>
+              <code>type=&lt;type&gt;;actions=create</code>
+            </li>
+            <li>
+              <code>type=&lt;type&gt;;actions=create:controller-led</code>
+            </li>
+          </ul>
           <li>
             <code>create:worker-led</code>: Create a worker using the worker-led workflow
           </li>

website/content/docs/configuration/worker/pki-worker.mdx

@@ -22,6 +22,46 @@ worker {
 }
 ```
 
+## Authorization Methods
+There are two mechanisms that can be used to register a worker to the cluster.
+
+### Controller-Led Authorization Flow
+In this flow, the operator fetches an activation token from the controller's
+`workers:create:controller-led` action (on the CLI, this is via `boundary
+workers create controller-led`). That activation token is given to the worker
+via the `controller_generated_activation_token` parameter. This can be done
+either directly or via an env var or file by using `env://` or `file://` syntax:
+
+```hcl
+worker {
+  worker {
+  auth_storage_path="/boundary/demo-worker-1"
+  initial_upstreams = ["10.0.0.1"]
+  controller_generated_activation_token = "neslat_........."
+  # controller_generated_activation_token = "env://ACT_TOKEN"
+  # controller_generated_activation_token = "file:///tmp/worker_act_token"
+}
+```
+
+Once the worker starts, it will read this token and use it to authorize to the
+cluster. Note that this token is one-time-use; it is safe to keep it here even
+after the worker has successfully authorized and authenticated, as it will be
+unusable at that point.
+
+Note: If this value is not present at worker startup time and the worker is not
+authorized, it will print and write out suitable information for the worker-led
+flow, described below. So long as the worker-led flow has not been used to
+authorize the worker, if the controller-generated activation token is provided
+and the worker restarted, it will make use of it.
+
+### Worker-Led Authorization Flow
+In this flow, the worker prints out an authorization request token to two
+places: the startup information printed to stdout, and a file called
+`auth_request_token` in the base of the configured `auth_storage_path`. This
+token can be submitted to a controller at the `workers:create:worker-led` path;
+on the CLI this would be via `boundary workers create worker-led
+-worker-generated-auth-token`. No values are needed in the configuration file.
+
 ## KMS Configuration
 PKI Workers credentials can be encrypted by including an optional KMS stanza with the purpose `worker-auth-storage`.