#825: Allow passing explicit connection to ACL.{reload,save}

[tseaver]

See #825

[coveralls]

Changes Unknown when pulling 0ed115b on tseaver:825-storage_acl-explicit_connection into * on GoogleCloudPlatform:master*.

[tseaver]

@dhermes PTAL

[coveralls]

Coverage remained the same at 100.0% when pulling 324dea7 on tseaver:825-storage_acl-explicit_connection into 8b5c5b9 on GoogleCloudPlatform:master.

[coveralls]

Coverage remained the same at 100.0% when pulling d4bc450 on tseaver:825-storage_acl-explicit_connection into 8b5c5b9 on GoogleCloudPlatform:master.

[tseaver]

@dhermes d4bc450 drops the "pure virtual" property implementation of reload_path and save_path, replacing them with a class attr default of None, allowing tests to assign to the ACL instances. Any remaining issues?

[dhermes]

LGTM.

@tseaver I'd like to have a pow-wow about the current state of our ACL support and try to figure out what we want (or better yet, what someone wants that's actually used ACLs for an application). Things are a bit out of place in the current state (e.g. roles is a set, but storage has a concept of concentric roles permissions for the very purpose of avoiding an ACL having more than one role).

[tseaver]

It is annyoing that those docs can't keep role vs. permisison straight, even on the same page.

If READER, WRITER, and OWNER are the only possible permissions / roles, then we could avoid having an ACE (a single assertion/entity, of which an ACL is a collection) have only one of them.

[tseaver]

We should also work out how to support the predefined ACLs feature