Reusing names of policy keys from policy_constants.h

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 6209b772ef9082b2c521d823b0cdd2ae0faea6f6..c7362dfafa36df38577c0177973486d6f0e530d7 100644
--- a/components/policy/resources/policy_templates.json
+++ b/components/policy/resources/policy_templates.json
@@ -123,7 +123,7 @@
 #   persistent IDs for all fields (but not for groups!) are needed. These are
 #   specified by the 'id' keys of each policy. NEVER CHANGE EXISTING IDs,
 #   because doing so would break the deployed wire format!
-#   For your editing convenience: highest ID currently used: 283
+#   For your editing convenience: highest ID currently used: 288
 #
 # Placeholders:
 #   The following placeholder strings are automatically substituted:
@@ -745,6 +745,95 @@
 
           If this policy is left not set, or if it is set to an empty string, the remote access host will be allowed to use any available port, unless the policy <ph name="REMOTEACCESSHOSTFIREWALLTRAVERSAL_POLICY_NAME">RemoteAccessHostFirewallTraversal</ph> is disabled, in which case the remote access host will use UDP ports in the 12400-12409 range.''',
         },
+        {
+          'name': 'RemoteAccessHostMatchUsername',
+          'type': 'main',
+          'schema': { 'type': 'boolean' },
+          'supported_on': ['chrome.*:36-'],
+          'supported_on DO NOT SUBMIT': 'simonmorris@chromium.org 2012-10-30 22:31:12 52ba3ea',
+          'features': {
+            'dynamic_refresh': True,
+            'per_profile': False,
+          },
+          'example_value': False,
+          'id': 284,
+          'caption': '''Requires that username of the local user and the host owner match''',
+          'desc': '''Requires that username of the local user and the host owner match.
+
+          If this setting is enabled, then the host will not start if the name of the host owner is different from the name of the local user that the host is associated with.
+
+          If this setting is disabled or not set, then the host can be associated with any local user.
+
+          This policy is ignored on Windows.''',

[Łukasz Anforowicz, 2014/12/24 00:58:09]

policy_watcher.h used to say:
  // This policy is currently considered 'internal only' and so is not
  // documented in policy_templates.json.

I don't understand what 'internal only' means in this context.  The policy name
is visible publicly in src/remoting/host/policy_hack/policy_watcher.h and
elsewhere under src/remoting.  

I think that even if the policy is meant for limited consumption, then it might
still make sense to include it in policy_templates.json:
- This will help get rid of src/remoting/host/policy_hack and reuse
PolicyService in the future,
- This will unify how policy names are defined and exposed to src/remoting
today.

+        },
+        {
+          'name': 'RemoteAccessHostTokenUrl',
+          'type': 'string',
+          'schema': { 'type': 'string' },
+          'supported_on': ['chrome.*:36-'],
+          'supported_on DO NOT SUBMIT': 'rmsousa@chromium.org 2013-04-06 04:50:43 4386f0a',

[Łukasz Anforowicz, 2014/12/24 00:58:09]

Can I please get some help or hints with mapping a git commit id into a chrome
version?

+          'features': {
+            'dynamic_refresh': True,
+            'per_profile': False,
+          },
+          'example_value': 'DO NOT SUBMIT',
+          'id': 285,
+          'caption': '''DO NOT SUBMIT''',

[Łukasz Anforowicz, 2014/12/24 00:58:09]

For the 3 RemoteAccessHostTokenXxx policies, I will need Renato's help for
filling out the caption, description and examples.

Let's first review this draft and agree that inclusion of Chromoting policies in
policy_templates.js is the right thing to do, and I can work with Renato on the
captions/descriptions afterwards.

+          'desc': '''DO NOT SUBMIT
+
+          DO NOT SUBMIT''',
+        },
+        {
+          'name': 'RemoteAccessHostTokenValidationUrl',
+          'type': 'string',
+          'schema': { 'type': 'string' },
+          'supported_on': ['chrome.*:36-'],
+          'supported_on DO NOT SUBMIT': 'rmsousa@chromium.org 2013-04-06 04:50:43 4386f0a',
+          'features': {
+            'dynamic_refresh': True,
+            'per_profile': False,
+          },
+          'example_value': 'DO NOT SUBMIT',
+          'id': 286,
+          'caption': '''DO NOT SUBMIT''',
+          'desc': '''DO NOT SUBMIT
+
+          DO NOT SUBMIT''',
+        },
+        {
+          'name': 'RemoteAccessHostTokenValidationCertificateIssuer',
+          'type': 'string',
+          'schema': { 'type': 'string' },
+          'supported_on': ['chrome.*:36-'],
+          'supported_on DO NOT SUBMIT': 'rmsousa@chromium.org 2014-01-25 01:46:03 7181799',
+          'features': {
+            'dynamic_refresh': True,
+            'per_profile': False,
+          },
+          'example_value': 'DO NOT SUBMIT',
+          'id': 287,
+          'caption': '''DO NOT SUBMIT''',
+          'desc': '''DO NOT SUBMIT
+
+          DO NOT SUBMIT''',
+        },
+        {
+          'name': 'RemoteAccessHostDebugOverridePolicies',
+          'type': 'string',
+          'schema': { 'type': 'string' },
+          'supported_on': ['chrome.*:36-'],
+          'supported_on DO NOT SUBMIT': 'wez@chromium.org 2012-11-13 10:08:38 158b287',
+          'features': {
+            'dynamic_refresh': True,
+            'per_profile': False,
+          },
+          'example_value': '{ "RemoteAccessHostMatchUsername": true }',
+          'id': 288,
+          'caption': '''Policy overrides for Debug builds of the host''',
+          'desc': '''Overrides policies on Debug builds of the host.
+
+          The value is parsed as a JSON dictionary of policy name to policy value mappings.''',
+        },

[Łukasz Anforowicz, 2014/12/24 00:58:09]

I think it is ok to include RemoteAccessHostDebugOverridePolicies here.  

I think that even if the policy is meant for limited consumption, then it might
still make sense to include it in policy_templates.json:
- This will help get rid of src/remoting/host/policy_hack and reuse
PolicyService in the future,
- This will unify how policy names are defined and exposed to src/remoting
today.

       ],
     },
     {