feat(servicemanagement): update the api

#### servicemanagement:v1

The following keys were added:
- schemas.GoSettings.properties.renamedServices (Total Keys: 2)

docs/dyn/servicemanagement_v1.services.configs.html

@@ -259,6 +259,7 @@ <h3>Method Details</h3>
     ],
   },
   &quot;documentation&quot;: { # `Documentation` provides the information for describing a service. Example: documentation: summary: &gt; The Google Calendar API gives access to most calendar features. pages: - name: Overview content: (== include google/foo/overview.md ==) - name: Tutorial content: (== include google/foo/tutorial.md ==) subpages: - name: Java content: (== include google/foo/tutorial_java.md ==) rules: - selector: google.calendar.Calendar.Get description: &gt; ... - selector: google.calendar.Calendar.Put description: &gt; ... Documentation is provided in markdown syntax. In addition to standard markdown features, definition lists, tables and fenced code blocks are supported. Section headers can be provided and are interpreted relative to the section nesting of the context where a documentation fragment is embedded. Documentation from the IDL is merged with documentation defined via the config at normalization time, where documentation provided by config rules overrides IDL provided. A number of constructs specific to the API platform are supported in documentation text. In order to reference a proto element, the following notation can be used: [fully.qualified.proto.name][] To override the display text used for the link, this can be used: [display text][fully.qualified.proto.name] Text can be excluded from doc using the following notation: (-- internal comment --) A few directives are available in documentation. Note that directives must appear on a single line to be properly identified. The `include` directive includes a markdown file from an external source: (== include path/to/file ==) The `resource_for` directive marks a message to be the resource of a collection in REST view. If it is not specified, tools attempt to infer the resource from the operations in a collection: (== resource_for v1.shelves.books ==) The directive `suppress_warning` does not directly affect documentation and is documented together with service config validation. # Additional API documentation.
+    &quot;additionalIamInfo&quot;: &quot;A String&quot;, # Optional information about the IAM configuration. This is typically used to link to documentation about a product&#x27;s IAM roles and permissions.
     &quot;documentationRootUrl&quot;: &quot;A String&quot;, # The URL to the root of documentation.
     &quot;overview&quot;: &quot;A String&quot;, # Declares a single overview page. For example: documentation: summary: ... overview: (== include overview.md ==) This is a shortcut for the following declaration (using pages style): documentation: summary: ... pages: - name: Overview content: (== include overview.md ==) Note: you cannot specify both `overview` field and `pages` field.
     &quot;pages&quot;: [ # The top level pages for the documentation set.
@@ -516,6 +517,9 @@ <h3>Method Details</h3>
               ],
             },
           },
+          &quot;renamedServices&quot;: { # Map of service names to renamed services. Keys are the package relative service names and values are the name to be used for the service client and call options. publishing: go_settings: renamed_services: Publisher: TopicAdmin
+            &quot;a_key&quot;: &quot;A String&quot;,
+          },
         },
         &quot;javaSettings&quot;: { # Settings for Java client libraries. # Settings for legacy Java features, supported in the Service YAML.
           &quot;common&quot;: { # Required information for every language. # Some settings.
@@ -921,6 +925,7 @@ <h3>Method Details</h3>
     ],
   },
   &quot;documentation&quot;: { # `Documentation` provides the information for describing a service. Example: documentation: summary: &gt; The Google Calendar API gives access to most calendar features. pages: - name: Overview content: (== include google/foo/overview.md ==) - name: Tutorial content: (== include google/foo/tutorial.md ==) subpages: - name: Java content: (== include google/foo/tutorial_java.md ==) rules: - selector: google.calendar.Calendar.Get description: &gt; ... - selector: google.calendar.Calendar.Put description: &gt; ... Documentation is provided in markdown syntax. In addition to standard markdown features, definition lists, tables and fenced code blocks are supported. Section headers can be provided and are interpreted relative to the section nesting of the context where a documentation fragment is embedded. Documentation from the IDL is merged with documentation defined via the config at normalization time, where documentation provided by config rules overrides IDL provided. A number of constructs specific to the API platform are supported in documentation text. In order to reference a proto element, the following notation can be used: [fully.qualified.proto.name][] To override the display text used for the link, this can be used: [display text][fully.qualified.proto.name] Text can be excluded from doc using the following notation: (-- internal comment --) A few directives are available in documentation. Note that directives must appear on a single line to be properly identified. The `include` directive includes a markdown file from an external source: (== include path/to/file ==) The `resource_for` directive marks a message to be the resource of a collection in REST view. If it is not specified, tools attempt to infer the resource from the operations in a collection: (== resource_for v1.shelves.books ==) The directive `suppress_warning` does not directly affect documentation and is documented together with service config validation. # Additional API documentation.
+    &quot;additionalIamInfo&quot;: &quot;A String&quot;, # Optional information about the IAM configuration. This is typically used to link to documentation about a product&#x27;s IAM roles and permissions.
     &quot;documentationRootUrl&quot;: &quot;A String&quot;, # The URL to the root of documentation.
     &quot;overview&quot;: &quot;A String&quot;, # Declares a single overview page. For example: documentation: summary: ... overview: (== include overview.md ==) This is a shortcut for the following declaration (using pages style): documentation: summary: ... pages: - name: Overview content: (== include overview.md ==) Note: you cannot specify both `overview` field and `pages` field.
     &quot;pages&quot;: [ # The top level pages for the documentation set.
@@ -1178,6 +1183,9 @@ <h3>Method Details</h3>
               ],
             },
           },
+          &quot;renamedServices&quot;: { # Map of service names to renamed services. Keys are the package relative service names and values are the name to be used for the service client and call options. publishing: go_settings: renamed_services: Publisher: TopicAdmin
+            &quot;a_key&quot;: &quot;A String&quot;,
+          },
         },
         &quot;javaSettings&quot;: { # Settings for Java client libraries. # Settings for legacy Java features, supported in the Service YAML.
           &quot;common&quot;: { # Required information for every language. # Some settings.
@@ -1595,6 +1603,7 @@ <h3>Method Details</h3>
     ],
   },
   &quot;documentation&quot;: { # `Documentation` provides the information for describing a service. Example: documentation: summary: &gt; The Google Calendar API gives access to most calendar features. pages: - name: Overview content: (== include google/foo/overview.md ==) - name: Tutorial content: (== include google/foo/tutorial.md ==) subpages: - name: Java content: (== include google/foo/tutorial_java.md ==) rules: - selector: google.calendar.Calendar.Get description: &gt; ... - selector: google.calendar.Calendar.Put description: &gt; ... Documentation is provided in markdown syntax. In addition to standard markdown features, definition lists, tables and fenced code blocks are supported. Section headers can be provided and are interpreted relative to the section nesting of the context where a documentation fragment is embedded. Documentation from the IDL is merged with documentation defined via the config at normalization time, where documentation provided by config rules overrides IDL provided. A number of constructs specific to the API platform are supported in documentation text. In order to reference a proto element, the following notation can be used: [fully.qualified.proto.name][] To override the display text used for the link, this can be used: [display text][fully.qualified.proto.name] Text can be excluded from doc using the following notation: (-- internal comment --) A few directives are available in documentation. Note that directives must appear on a single line to be properly identified. The `include` directive includes a markdown file from an external source: (== include path/to/file ==) The `resource_for` directive marks a message to be the resource of a collection in REST view. If it is not specified, tools attempt to infer the resource from the operations in a collection: (== resource_for v1.shelves.books ==) The directive `suppress_warning` does not directly affect documentation and is documented together with service config validation. # Additional API documentation.
+    &quot;additionalIamInfo&quot;: &quot;A String&quot;, # Optional information about the IAM configuration. This is typically used to link to documentation about a product&#x27;s IAM roles and permissions.
     &quot;documentationRootUrl&quot;: &quot;A String&quot;, # The URL to the root of documentation.
     &quot;overview&quot;: &quot;A String&quot;, # Declares a single overview page. For example: documentation: summary: ... overview: (== include overview.md ==) This is a shortcut for the following declaration (using pages style): documentation: summary: ... pages: - name: Overview content: (== include overview.md ==) Note: you cannot specify both `overview` field and `pages` field.
     &quot;pages&quot;: [ # The top level pages for the documentation set.
@@ -1852,6 +1861,9 @@ <h3>Method Details</h3>
               ],
             },
           },
+          &quot;renamedServices&quot;: { # Map of service names to renamed services. Keys are the package relative service names and values are the name to be used for the service client and call options. publishing: go_settings: renamed_services: Publisher: TopicAdmin
+            &quot;a_key&quot;: &quot;A String&quot;,
+          },
         },
         &quot;javaSettings&quot;: { # Settings for Java client libraries. # Settings for legacy Java features, supported in the Service YAML.
           &quot;common&quot;: { # Required information for every language. # Some settings.
@@ -2269,6 +2281,7 @@ <h3>Method Details</h3>
         ],
       },
       &quot;documentation&quot;: { # `Documentation` provides the information for describing a service. Example: documentation: summary: &gt; The Google Calendar API gives access to most calendar features. pages: - name: Overview content: (== include google/foo/overview.md ==) - name: Tutorial content: (== include google/foo/tutorial.md ==) subpages: - name: Java content: (== include google/foo/tutorial_java.md ==) rules: - selector: google.calendar.Calendar.Get description: &gt; ... - selector: google.calendar.Calendar.Put description: &gt; ... Documentation is provided in markdown syntax. In addition to standard markdown features, definition lists, tables and fenced code blocks are supported. Section headers can be provided and are interpreted relative to the section nesting of the context where a documentation fragment is embedded. Documentation from the IDL is merged with documentation defined via the config at normalization time, where documentation provided by config rules overrides IDL provided. A number of constructs specific to the API platform are supported in documentation text. In order to reference a proto element, the following notation can be used: [fully.qualified.proto.name][] To override the display text used for the link, this can be used: [display text][fully.qualified.proto.name] Text can be excluded from doc using the following notation: (-- internal comment --) A few directives are available in documentation. Note that directives must appear on a single line to be properly identified. The `include` directive includes a markdown file from an external source: (== include path/to/file ==) The `resource_for` directive marks a message to be the resource of a collection in REST view. If it is not specified, tools attempt to infer the resource from the operations in a collection: (== resource_for v1.shelves.books ==) The directive `suppress_warning` does not directly affect documentation and is documented together with service config validation. # Additional API documentation.
+        &quot;additionalIamInfo&quot;: &quot;A String&quot;, # Optional information about the IAM configuration. This is typically used to link to documentation about a product&#x27;s IAM roles and permissions.
         &quot;documentationRootUrl&quot;: &quot;A String&quot;, # The URL to the root of documentation.
         &quot;overview&quot;: &quot;A String&quot;, # Declares a single overview page. For example: documentation: summary: ... overview: (== include overview.md ==) This is a shortcut for the following declaration (using pages style): documentation: summary: ... pages: - name: Overview content: (== include overview.md ==) Note: you cannot specify both `overview` field and `pages` field.
         &quot;pages&quot;: [ # The top level pages for the documentation set.
@@ -2526,6 +2539,9 @@ <h3>Method Details</h3>
                   ],
                 },
               },
+              &quot;renamedServices&quot;: { # Map of service names to renamed services. Keys are the package relative service names and values are the name to be used for the service client and call options. publishing: go_settings: renamed_services: Publisher: TopicAdmin
+                &quot;a_key&quot;: &quot;A String&quot;,
+              },
             },
             &quot;javaSettings&quot;: { # Settings for Java client libraries. # Settings for legacy Java features, supported in the Service YAML.
               &quot;common&quot;: { # Required information for every language. # Some settings.

docs/dyn/servicemanagement_v1.services.html

@@ -454,6 +454,7 @@ <h3>Method Details</h3>
     ],
   },
   &quot;documentation&quot;: { # `Documentation` provides the information for describing a service. Example: documentation: summary: &gt; The Google Calendar API gives access to most calendar features. pages: - name: Overview content: (== include google/foo/overview.md ==) - name: Tutorial content: (== include google/foo/tutorial.md ==) subpages: - name: Java content: (== include google/foo/tutorial_java.md ==) rules: - selector: google.calendar.Calendar.Get description: &gt; ... - selector: google.calendar.Calendar.Put description: &gt; ... Documentation is provided in markdown syntax. In addition to standard markdown features, definition lists, tables and fenced code blocks are supported. Section headers can be provided and are interpreted relative to the section nesting of the context where a documentation fragment is embedded. Documentation from the IDL is merged with documentation defined via the config at normalization time, where documentation provided by config rules overrides IDL provided. A number of constructs specific to the API platform are supported in documentation text. In order to reference a proto element, the following notation can be used: [fully.qualified.proto.name][] To override the display text used for the link, this can be used: [display text][fully.qualified.proto.name] Text can be excluded from doc using the following notation: (-- internal comment --) A few directives are available in documentation. Note that directives must appear on a single line to be properly identified. The `include` directive includes a markdown file from an external source: (== include path/to/file ==) The `resource_for` directive marks a message to be the resource of a collection in REST view. If it is not specified, tools attempt to infer the resource from the operations in a collection: (== resource_for v1.shelves.books ==) The directive `suppress_warning` does not directly affect documentation and is documented together with service config validation. # Additional API documentation.
+    &quot;additionalIamInfo&quot;: &quot;A String&quot;, # Optional information about the IAM configuration. This is typically used to link to documentation about a product&#x27;s IAM roles and permissions.
     &quot;documentationRootUrl&quot;: &quot;A String&quot;, # The URL to the root of documentation.
     &quot;overview&quot;: &quot;A String&quot;, # Declares a single overview page. For example: documentation: summary: ... overview: (== include overview.md ==) This is a shortcut for the following declaration (using pages style): documentation: summary: ... pages: - name: Overview content: (== include overview.md ==) Note: you cannot specify both `overview` field and `pages` field.
     &quot;pages&quot;: [ # The top level pages for the documentation set.
@@ -711,6 +712,9 @@ <h3>Method Details</h3>
               ],
             },
           },
+          &quot;renamedServices&quot;: { # Map of service names to renamed services. Keys are the package relative service names and values are the name to be used for the service client and call options. publishing: go_settings: renamed_services: Publisher: TopicAdmin
+            &quot;a_key&quot;: &quot;A String&quot;,
+          },
         },
         &quot;javaSettings&quot;: { # Settings for Java client libraries. # Settings for legacy Java features, supported in the Service YAML.
           &quot;common&quot;: { # Required information for every language. # Some settings.