[Fleet] Add docs for re-enrolling multiple agents after migration

[karenzone]

Closes: #2577

• On 9.1.0 and earlier, you need to run commands on each individual host to re-enroll agents.
• On 9.2.0 and later, you can migrate remote agents directly from the Fleet UI, eliminating the need to run commands on each individual host.

Preview: https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/3216/reference/fleet/migrate-elastic-agent#migrate-elastic-agent-migrated-agents

[github-actions]

🔍 Preview links for changed docs

• reference/fleet/migrate-elastic-agent.md

[karenzone]

Seeking early feedback.

@michalpristas here's an early look so you can see how this doc is shaping up.
@colleenmcginnis please let me know what you think about this approach to versioning.

[michalpristas]

note: non implemented yet but we will fail migration for agents that are in the process of upgrade including Watching period - this applies only for migration not calling enroll manually

[michalpristas]

probably worth specifying it's enroll command that needs to be run

[colleenmcginnis]

Using 9.2.0 and 9.1.0 as the tab titles might be confusing because:

• What about versions before 9.1.0 or 9.1.x versions after 9.1.0? It's not clear to the reader without interacting with the tab that it's possible to do this at all in 9.0.x or 9.1.1 - 9.1.5.
• For the most part, we have been using version tabs to specify the version a feature was added / made available rather than the last version in which is was available.
• Is it still possible to run commands on each individual host in 9.2.0 or does the user have to use the Fleet UI starting in 9.2.0? (Note: My recommended approach below assumes it's possible to use the command OR UI in 9.2.0+.)
• Hard-coding the 9.2.0 in the tab title and in the text means that you need to hold on merging this PR until the 9.2.0 release date or we will be making promises about future releases.

I wonder if it would be clearer to do something like this:

And the Command line tab:

Markdown syntax

5. Choose an approach:

    ::::{tab-set}
    :::{tab-item} Fleet UI

    {applies_to}`stack: ga 9.2` Migrate remote agents directly from the {{fleet}} UI:

    1. In the source cluster, select the agents you want to migrate. Click the three dots next to the agents, and select **Migrate agents**.
    2. In the migration dialog, provide the URI and enrollment token you obtained from the target cluster.
    3. Use replace_token (Optional): When you are migrating a single agent, you can use the `replace_token` field to preserve the agent's original ID from the source cluster. This step helps with event matching, but will cause the migration to fail if the target cluster already has an agent with the same ID.
    :::

    :::{tab-item} Command line
    Run commands on each individual host:

    1. On the host machines where the current agents are installed, enroll the agents again using this copied URL and the enrollment token:

        ```shell
        sudo elastic-agent enroll --url=<fleet server url> --enrollment-token=<token for the new policy>
        ```

        The command output should resemble this:

        :::{image} images/migrate-agent-install-command-output.png
        :alt: Install command output
        :screenshot:
        :::

    2. The agent on each host will now check into the new {{fleet-server}} and appear in the new target cluster. In the source cluster, the agents will go offline as they won’t be sending any check-ins.

        :::{image} images/migrate-agent-newly-enrolled-agents.png
        :alt: Newly enrolled agents in the target cluster
        :screenshot:
        :::

    3. Repeat this procedure for each {{agent}} policy.
    :::
    ::::

[karenzone]

@colleenmcginnis, I agree that there is room for confusion. I was following the previous set guidelines we used here:

Is this approach still appropriate for smaller sets of content such as in the previous example?

Thanks for the new proposal. I'll take a look.