feat(all): auto-regenerate discovery clients (#3202)

Author: yoshi-automation

bigtableadmin/v2/bigtableadmin-api.json

@@ -2868,7 +2868,7 @@
       }
     }
   },
-  "revision": "20250512",
+  "revision": "20250610",
   "rootUrl": "https://bigtableadmin.googleapis.com/",
   "schemas": {
     "AppProfile": {
@@ -5131,6 +5131,10 @@
           "$ref": "TableStats",
           "description": "Output only. Only available with STATS_VIEW, this includes summary statistics about the entire table contents. For statistics about a specific column family, see ColumnFamilyStats in the mapped ColumnFamily collection above.",
           "readOnly": true
+        },
+        "tieredStorageConfig": {
+          "$ref": "TieredStorageConfig",
+          "description": "Rules to specify what data is stored in each storage tier. Different tiers store data differently, providing different trade-offs between cost and performance. Different parts of a table can be stored separately on different tiers. If a config is specified, tiered storage is enabled for this table. Otherwise, tiered storage is disabled. Only SSD instances can configure tiered storage."
         }
       },
       "type": "object"
@@ -5224,6 +5228,29 @@
       },
       "type": "object"
     },
+    "TieredStorageConfig": {
+      "description": "Config for tiered storage. A valid config must have a valid TieredStorageRule. Otherwise the whole TieredStorageConfig must be unset. By default all data is stored in the SSD tier (only SSD instances can configure tiered storage).",
+      "id": "TieredStorageConfig",
+      "properties": {
+        "infrequentAccess": {
+          "$ref": "TieredStorageRule",
+          "description": "Rule to specify what data is stored in the infrequent access(IA) tier. The IA tier allows storing more data per node with reduced performance."
+        }
+      },
+      "type": "object"
+    },
+    "TieredStorageRule": {
+      "description": "Rule to specify what data is stored in a storage tier.",
+      "id": "TieredStorageRule",
+      "properties": {
+        "includeIfOlderThan": {
+          "description": "Include cells older than the given age. For the infrequent access tier, this value must be at least 30 days.",
+          "format": "google-duration",
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
     "Type": {
       "description": "`Type` represents the type of data that is written to, read from, or stored in Bigtable. It is heavily based on the GoogleSQL standard to help maintain familiarity and consistency across products and features. For compatibility with Bigtable's existing untyped APIs, each `Type` includes an `Encoding` which describes how to convert to or from the underlying data. Each encoding can operate in one of two modes: - Sorted: In this mode, Bigtable guarantees that `Encode(X) \u003c= Encode(Y)` if and only if `X \u003c= Y`. This is useful anywhere sort order is important, for example when encoding keys. - Distinct: In this mode, Bigtable guarantees that if `X != Y` then `Encode(X) != Encode(Y)`. However, the converse is not guaranteed. For example, both \"{'foo': '1', 'bar': '2'}\" and \"{'bar': '2', 'foo': '1'}\" are valid encodings of the same JSON value. The API clearly documents which mode is used wherever an encoding can be configured. Each encoding also documents which values are supported in which modes. For example, when encoding INT64 as a numeric STRING, negative numbers cannot be encoded in sorted mode. This is because `INT64(1) \u003e INT64(-1)`, but `STRING(\"-00001\") \u003e STRING(\"00001\")`.",
       "id": "Type",