Reset user data directory and disk cache directory after downgrade.

components/policy/resources/policy_templates.json

Index: components/policy/resources/policy_templates.json
diff --git a/components/policy/resources/policy_templates.json b/components/policy/resources/policy_templates.json
index edd7c26bbcd49a8ee7b930f6be40e1e03c92ee58..406dd847b692693d631a548eb0b927a2d8e8bc94 100644
--- a/components/policy/resources/policy_templates.json
+++ b/components/policy/resources/policy_templates.json
@@ -1415,7 +1415,9 @@
 
       See https://www.chromium.org/administrators/policy-list-3/user-data-directory-variables for a list of variables that can be used.
 
-      If this policy is left not set the default profile path will be used and the user will be able to override it with the '--user-data-dir' command line flag.''',
+      If this policy is left not set the default profile path will be used and the user will be able to override it with the '--user-data-dir' command line flag.
+
+      This policy must not be set to a volume's root directory, and should not be set to a directory used for other purposes.''',

[pastarmovj, 2016/06/01 15:09:40]

Can you explain to me why is this the case? I don't think this is really
impossible only it is a bad choice I guess. Or do you mean this would cause your
profile deletion logic to wipe the hard drive? 8-|

Regardless of the discussion above I think this paragraph belongs above the
paragraph "If this policy is not set...".

[zmin, 2016/06/01 15:34:30]

No, it won't wipe the hard drive. However, there is no easy way for us to delete
a directory if it's set to root directory. Because we can't move root directory
before delete like others and delete without move causes many other issues (too
slow, partially delete).
As a result, if the |user_data_dir| or |disk_cache_dir| is set to root
directory, the removing code will simply be skipped.

Because root directory can potentially cause issues after the downgrade and it's
hard for us to explain why as we don't want to document downgrade feature
publicly. I think it's just good to tell the users to avoid using it even though
Admins can still set it at their own risk.

I'll combine this paragraph with the above one. 

[zmin, 2016/06/01 15:45:22]

Actually, I'll put it behind the paragraph of 'If you set this policy, .... " as
they are both talking about "set".

[pastarmovj, 2016/06/02 10:04:35]

I understand that we don't want to have a lengthy and potentially hard to follow
conversation here why is this the case. But at least let's have something like
"To avoid data loss this policy should not be set to a volume's root directory
or to a directory used for other purposes, because <ph
name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph> manages its contents." or some
such. It still doesn't go into detail but kind of gives the idea of why is this
not a great idea. WDYT?

       'label': '''Set user data directory''',
     },
     {
@@ -1437,7 +1439,9 @@
 
       See https://www.chromium.org/administrators/policy-list-3/user-data-directory-variables for a list of variables that can be used.
 
-      If this policy is left not set the default cache directory will be used and the user will be able to override it with the '--disk-cache-dir' command line flag.''',
+      If this policy is left not set the default cache directory will be used and the user will be able to override it with the '--disk-cache-dir' command line flag.
+
+      This policy must not be set to a volume's root directory, and should not be set to a directory used for other purposes.''',

[pastarmovj, 2016/06/01 15:09:40]

Ditto.

[zmin, 2016/06/01 15:34:29]

Done.

       'label': '''Set disk cache directory''',
     },
     {