1. Proposed title of this feature request 

More documentation for the default settings of "ior_enabled" & "autoscaleenabled" when installing service mesh v2

2. What is the nature and description of the request?

The documentation once specified "ior_enabled" as "true" while "autoscaleenabled" remained "false", however, when installing service mesh V2 these appear to be incorrect unless a custom CR is defined. 

  
3. Why does the customer need this? (List the business requirements here)

To determine if a custom CR is needed to do a mass ansible installation and rollout.   

4. List any affected packages or components.

• Service Mesh V2 - istiod | pilot, citadel and galley

• OCP 4.6 

5. Additional Notes & Docs: 

• Basic-install.yaml

.: {}
f:autoscaleEnabled: {}
f:enabled: {}
–
--
.: {}
f:autoscaleEnabled: {}
f:enableProtocolSniffingForInbound: {}
–
--
istio-egressgateway:
autoscaleEnabled: false
enabled: true
–
--
istio-ingressgateway:
autoscaleEnabled: false
enabled: true
–
--
policy:
autoscaleEnabled: false
enabled: false
–
--
telemetry:
autoscaleEnabled: false
enabled: false
–
--
pilot:
autoscaleEnabled: false
enableProtocolSniffingForInbound: false
~~~
eploying service mesh 1.x shows the following:
~~~
istio-citadel-774d9f7874-zhxlt 1/1 Running 0 25m
istio-galley-576ffc887d-mwtch 1/1 Running 0 25m
istio-pilot-7cc44f6fcf-w7k6g 2/2 Running 0 25m
~~~
1.7.6. Deploying the Red Hat OpenShift Service Mesh control plane
https://access.redhat.com/documentation/en-us/openshift_container_platform/4.3/html-single/service_mesh/index
service mesh 2.x deployment doc
https://access.redhat.com/documentation/en-us/openshift_container_platform/4.6/html/service_mesh/index
~~~
1.3.1. Red Hat OpenShift Service Mesh multitenant installation
Whereas upstream Istio takes a single tenant approach, Red Hat OpenShift Service Mesh supports multiple independent control planes within the cluster.
Red Hat OpenShift Service Mesh uses a multitenant operator to manage the control plane lifecycle.

Red Hat OpenShift Service Mesh installs a multitenant control plane by default. You specify the projects that can access the Service Mesh, and isolate
the Service Mesh from other control plane instances.
~~~
Introduces a re-architected control plane. The Mixer component has been deprecated and will be removed in a future release.
The other control plane components, Pilot, Galley, Citadel, have been combined into a single binary known as Istiod. The "d" stands for daemon.
~~~

>>> TEST
ServiceMesh 2.x should have no problem consolidating v1 and v2 control planes.
Can not seem to reproduce issue:
~~~
[quicklab@upi-0 ~]$ oc get pod -n openshift-operators
NAME READY STATUS RESTARTS AGE
istio-operator-d897f4c9b-zmtzg 1/1 Running 1 16h
jaeger-operator-5bbcbdd998-pl8nb 1/1 Running 0 16h
kiali-operator-cb5fdf769-fc7ld 1/1 Running 0 16h
~~~