[v17] Machine ID: Update documentation to reflect tbot CLI changes (#…

…48656)

* Machine ID: Update documentation to reflect tbot CLI changes

This updates the tbot documentation to reflect the new UX changes
for v17, including the new `tbot start` subcommands and runtime ACL
management.

* Add `tctl bots instances` subcommand reference docs

Also tweaks troubleshooting steps to reference the new tctl
subcommands for simpler instance creation.

* Fix a few docs lints

* Small wording fix

* Linter appeasement

* More linter appeasement

* Update docs/pages/reference/cli/tbot.mdx

Co-authored-by: Paul Gottschling <[email protected]>

* Adjust wording to explicitly state "example" is the bot name

---------

Co-authored-by: Paul Gottschling <[email protected]>

docs/pages/enroll-resources/machine-id/troubleshooting.mdx

@@ -31,6 +31,13 @@ some additional context:
 
 ### Explanation
 
+<Notice type="note">
+This applies only to bots using the `token` join method, which makes use of
+one-time use shared secrets. Provider-specific join methods, such as GitHub,
+AWS IAM, etc will not be locked in this fashion unless another instance of the
+bot uses `token` joining.
+</Notice>
+
 Machine ID (with token-based joining) uses a certificate generation counter to
 detect potentially stolen renewable certificates. Each time a bot fetches a new
 renewable certificate, the Auth Service increments the counter, stores it on the
@@ -69,9 +76,11 @@ directories (usually `/opt/machine-id`) rather than the internal data directory
 Once you have addressed the underlying cause, follow these steps to reset a
 locked bot:
  1. Remove the lock on the bot's user
- 1. Reset the bot's generation counter by deleting and re-creating the bot
+ 1. Reset the bot's generation counter by creating a new bot instance
 
-To remove the lock, first find and remove the lock targeting the bot user:
+To remove the lock, first find and remove the lock targeting the bot user. For
+this example, we'll assume the bot is named `example`, which will have an
+associated Teleport user named `bot-example`:
 
 ```code
 $ tctl get locks
@@ -89,15 +98,16 @@ version: v2
 $ tctl rm lock/5cee949f-5203-4f3b-9805-dac35d798a16
 ```
 
-Next, reset the generation counter by deleting and recreating the bot:
+Next, use `tctl bots instances add` to generate a new join token for the
+preexisting bot `example`:
 ```code
-$ tctl bots rm example
-
-$ tctl bots add example --roles=foo,bar
+$ tctl bots instances add example
 ```
 
-Finally, reconfigure the bot with the new token and restart it. It will detect
-the new token and automatically reset its internal data directory.
+Finally, reconfigure the local `tbot` instance with the new token and restart
+it. It will detect the new token and automatically reset its internal data
+directory. The bot will be issued a new bot instance UUID once connected, and
+the generation counter will be reset.
 
 ## `tbot` shows a "bad certificate error" at startup
 
@@ -123,8 +133,8 @@ fail."
 
 Token-joined bots are unable to reauthenticate to the Teleport Auth Service once
 their certificates have expired. Tokens in token-based joining (as opposed to
-AWS IAM joining) can only be used once, so when the bot's internal certificates
-expire, it will not be able to connect.
+AWS IAM and other join methods) can only be used once, so when the bot's
+internal certificates expire, it will not be able to connect.
 
 When a bot's identity expires, certain parameters associated with the bot on the
 Auth Service must be reset and a new joining token must be issued. The simplest
@@ -133,11 +143,10 @@ server-side data and issues a new joining token.
 
 ### Resolution
 
-Remove and recreate the bot, replacing the name and role list as desired:
+Use `tctl bots instances add` to create a new one-time use token for the bot:
 
 ```code
-$ tctl bots rm example
-$ tctl bots add example --roles=access
+$ tctl bots instances add example
 ```
 
 Copy the resulting join token into the existing bot config—either the