Create an informative issue (See each section, incomplete templates/issues won't be triaged)

Using the current documentation as a model, please complete the issue template. 

Note: Doc team updates the current version and the two previous versions (n-2). For earlier versions, we will address only high-priority, customer-reported issues for releases in support.

Prerequisite: Start with what we have

Always look at the current documentation to describe the change that is needed. Use the source or portal link for Step 4:

 - Use the Customer Portal: https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes

 - Use the GitHub link to find the staged docs in the repository: https://github.com/stolostron/rhacm-docs 

Describe the changes in the doc and link to your dev story

Provide info for the following steps:

1. - [ x] Mandatory Add the required version to the Fix version/s field.

2. - [ ] Mandatory Choose the type of documentation change.

      - [ ] New topic in an existing section or new section
      - [x ] Update to an existing topic

3. - [ ] Mandatory for GA content:
            
       - [ ] Add steps and/or other important conceptual information here: 
       
            
       - [ ] Add Required access level for the user to complete the task here:
       

       - [ ] Add verification at the end of the task, how does the user verify success (a command to run or a result to see?)
     
     
       - [ ] Add link to dev story here:

4. - [ ] Mandatory for bugs: What is the diff? Clearly define what the problem is, what the change is, and link to the current documentation:

related to slack https://redhat-internal.slack.com/archives/CU4QXLPQB/p1698849666388959?thread_ts=1698684405.583309&cid=CU4QXLPQB

This section , point 2 and note below is confusing and misleading 

https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.8/html/business_continuity/business-cont-overview#preparing-clusters-activation-data

Issues: 

Point 2 and Note above are confusing, letting the user think that he must set

The Note: is linked to point 2 ; but this is not clear

>>> 2. If you want to use an existing managed cluster as the restore hub, set spec.disableHubSelfManagement=true for a passive cluster

Fix:

Remove point 2 and Note; they are intended to explain what happen when you try to use a managed cluster as a passive hub. Not an officially supported scenario and not properly presented there anyway ( point 2 was extracted from this poc https://docs.google.com/presentation/d/1Pph7HeOFnoixZF26_Usup1Mp59r5Sp00/edit#slide=id.g13c3abb0692_0_23 ; looks out of context there )

We'll open a new task if we need to doc this scenario