Turn off Storage regression tests

@ryanseys

Temporarily, to allow us to release 0.13.0?

The latest error in the continuing story of Travis regression test API errors:

Error: The total number of changes to the object gcloud-test-bucket-temp-9fd89ba0-c7f7-11e4-b6db-e3fe66d4cdb7/CloudPlatform_128px_Retina.png exceeds the rate limit. Please reduce the rate of create, update, and delete requests.

- https://travis-ci.org/GoogleCloudPlatform/gcloud-node/#L1865

Related: The project exceeded the rate limit for creating and deleting buckets. #411

@ryanseys can better detail the steps we've taken to get around the errors, but some of them unfortunately include removing iojs and Node 0.10 Travis instances.

We need to release to get accurate bug reports before calling ourselves stable.

// @jgeewax

We are now getting storage rate limits like before. We need npm permissions so we can ship without travis because rate limits are getting in the way.

+1 to npm perms

And silly idea - do you think using randomly generated file names in storage will help?

No, unless we are modifying different files for each test because we modify the same file over and over and then the rate limit kicks in.

Randomly generated bucket names worked to our disadvantage as well... we hit a rate limit on the number of buckets we could create in a small amount of time.

No, unless we are modifying different files for each test because we modify the same file over and over and then the rate limit kicks in.

That's what I'm thinking - different remote files per test.

We need to be white-listed and stop worrying about rate limiting for our tests. If there's one thing we've thoroughly tested here it's the rate limit detector mechanism.

I wonder how the other gcloud-* projects are able to get around the limits. Not disregarding your points (which I agree with), but is there anyone from those projects who can look over our tests and help us out/generalize their approach? (JJ)

Other guys (I believe) are using exponential back-off to get things to actually pass. I'm asking around to see what we need to do to be whitelisted and get around these quotas.

We (python) don't use any exponential backoff, but we might not be making as many API requests as you are. We only run the regression tests on merges to master, so rarely get a 429. Is that something you are doing or do you run them on every Travis build?