Add FAQ for cluster-wide feature for Cells 1.0

Many groups ask for about this, so offer some guidance on what to
expect, and what to do.

doc/architecture/blueprints/cells/index.md

@@ -365,8 +365,11 @@ Cluster-wide features are strongly discouraged because:
 - They might require implementation of non-trivial [data aggregation](goals.md#aggregation-of-cluster-wide-data) that reduces resilience to [single node failure](goals.md#high-resilience-to-a-single-cell-failure).
 - They are harder to build due to the need of being able to run [mixed deployments](goals.md#cells-running-in-mixed-deployments). Cluster-wide features need to take this into account.
 - They might affect our ability to provide an [on-premise like experience on GitLab.com](goals.md#on-premise-like-experience).
-- Some features that are expected to be cluster-wide might in fact be better implemented using federation techniques that use trusted intra-cluster communication using the same user identity. User Profile is shared across the cluster.
-- The Cells architecture limits what services can be considered cluster-wide. Services that might initially be cluster-wide are still expected to be split in the future to achieve full service isolation. No feature should be built to depend on such a service (like Elasticsearch).
+- Some features that are expected to be cluster-wide might in fact be better implemented using aggregation techniques that use trusted intra-cluster communication using the same user identity.
+  For example, user Profile is shared across the cluster.
+- The Cells architecture limits what services can be considered cluster-wide.
+  Services that might initially be cluster-wide are still expected to be split in the future to achieve full service isolation.
+  No feature should be built to depend on such a service (like Elasticsearch).
 
 ### Will Cells use the [reference architecture for 50,000 users](../../../administration/reference_architectures/50k_users.md)?
 

doc/architecture/blueprints/cells/iterations/cells-1.0.md

@@ -702,3 +702,27 @@ The table below is a comparison between the existing GitLab.com features, and no
    - Geo is per-Cell.
    - Routing Service can direct to Geo replica of the Cell (if it knows it).
    - We might have many routing services in many regions.
+
+1. Are cluster-wide tables available to all cells?
+
+   No, cluster-wide tables are stored in a Cell-local database. However, we will
+   determine synchronization of cluster-wide tables on a case by case basis.
+
+1. How can I adapt a feature to be compatible with Cells?
+
+   Many groups have questions about how to adapt a feature for Cell.
+   This especially applies if a feature is available at the instance level, or
+   can be used across groups.
+
+   Here are some strategies for evolving a thing for Cells 1.0:
+
+   - Leave the feature unchanged.
+     For example, admins / users will have to create an account per cell.
+   - Disable the feature for Cells 1.0.
+   - For critical cases, move the feature to cluster-wide level.
+     For example, users can sign in at a single location, `https://gitlab.com/users/sign_in`.
+
+   In many cases, it is not yet necessary to re-implement an instance-wide feature
+   to work on a cluster-wide level. This is because for Cells 1.0, the net
+   effect of only allowing private visibility and new users mean that we can
+   defer this until Cells 1.5.