Adding storage.api._require_connection to allow fallback behavior.

…-samples#779)

* Draft of first half of KMS samples

* reversed wrong change

* KMS Apiary Python samples - P1

* Few minor style issues

* Adding back in space i accidentally deleted

* Addressed all code review comments

* Renamed api directory to api-client

* Addressed more code review comments

* Formatting change

* Fix quickstart test

Change-Id: Ib79dc1345c9c40547f3fd4e9c3c9a48963a3b399

* Update readme

Change-Id: Icf4a66083f56d6f51be76ba1cf3b5dc8daf2c4c1

* Add readme

Change-Id: I2fbaa55092ef8787f1423d499aa310cab258c0c1

* Added parsers

* Final minor changes to parsers

* Added autogenerated README

* Changed snippets_test keyring name and cryptokey name

Currently, creating async clients with constructor works fine:

from google.cloud import vision

client = vision.ImageAnnotatorAsyncClient()
print(type(client))
prints: <class 'google.cloud.vision_v1.services.image_annotator.async_client.ImageAnnotatorAsyncClient'>

Using from_service_account_* methods on the other hand return sync client:

client = vision.ImageAnnotatorAsyncClient.from_service_account_file("service_account.json")
print(type(client))
This gives <class 'google.cloud.vision_v1.services.image_annotator.client.ImageAnnotatorClient'>, which is just a normal synchronous client.

This happens because these functions are linked to sync clients' methods. Now it's fixed to call the same method, but with proper class.

Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com>

Ensure both referred and constrained columns reported by
`get_multi_foreign_keys` are in the same order matching the constraint
declaration. Uses information for the unique constraint corresponding
to the foreign key constraint in order to ensure its columns are
ordered correctly.

Previously, the `CONSTRAINT_COLUMN` view in the information schema was
used to retrieve the referred columns, and that view offers no
information about column order. Instead, we use the KEY_COLUMN_USAGE
view for the corresponding unique constraint, which is ordered.

This requires consulting the `REFERENTIAL_CONSTRAINTS` view in order
to find the unique constraint associated with the foreign
key. Unfortunately, this view has a [bug in the
emulator](GoogleCloudPlatform/cloud-spanner-emulator#279)
related to cross-schema foreign keys. I had to skip a test for
cross-schema foreign keys due to the emulator issue. I've confirmed a
real spanner does not have this issue.

fixes: #779