Storage: Support bucket.location_type

[JesseLovelace]

Location type is a new read-only field for buckets. This corresponds to internal bug 130187277.

[crwilcox]

@JesseLovelace could you add a few more details here?

[stephenplusplus]

In absence of more details, I thought I'd add this suggestion in case it applies:

bucket.getMetadata((err, metadata) => {
  // metadata.locationType
})

[crwilcox]

@stephenplusplus that seems correct. Here is some more info to get you started.

Location type will be a new field added for Bucket resource. It will be populated on-the-fly for output path, and is a read-only field so patch/update/create will not have any effect on bucket resource.
Example

Google Cloud Storage Python client library feature request: Add location type on bucket

// Get bucket
storage_client = storage.Client()
bucket = storage_client.get_bucket("bucket-name")

// Get location type
location_type = bucket.location_type

// Request:
// GET https://www.googleapis.com/storage/v1/b/bucket-name?fields=locationType
// Response Body
// {
//   "locationType": "multi-region"
// }

[JesseLovelace]

Note: The current location type values are "MULTI_REGION", "REGION", and" DUAL_REGION", however these were supposed to be "multi-region", "region", and "dual-region". They will be changed in the API after a rollout on June 26 and that should also be reflected here.

[callmehiphop]

@JesseLovelace if this is changing what storageClass represents, does that mean we should deprecate our setStorageClass method?

As far as supporting the locationType property itself, we just store any Bucket response objects as a metadata field, so as soon as the feature goes live it will be available to users without a code change.

[JesseLovelace]

Not quite, setStorageClass will and should still work, but the Regional and Multi-regional storage classes will be considered legacy/deprecated.

The feature is already live, so if it works without a code change then including it in tests and documentation should be sufficient