Implement the static ACL chain

[sanderpick]

For each new thread, a JSON ACL doc can be built by the client lib:

{
  "$w": ["a", "b"], // these keys can add records
  "$r": ["*"], // these keys can get thread, get record, pull thread, and subscribe
  "$d": ["a"], // these keys can delete the thread
  "$s": ["*"], // these keys can add services like a replicator
}

Some notes:

• * is anyone.
• The hash of the ACL can be derived from the static thread.ID. This means that the ACL and it's rules can be independently verified / enforced by anyone who has the ACL and thread.ID.
• Since threads does not concern itself with pinning, I've been thinking that these ACL docs can just be sent allow with push log requests. This would ensure that everyone has the ACL who needs it.
• In order to enforce the rules, a peer needs some proof of the caller's identity. Does the caller control the associated private key? If so, check the rules... can they write? read? etc. Is the rule a * rule? If so, it doesn't matter.

This PR is enabling the last piece.

Originally posted by @sanderpick in https://github.com/textileio/go-threads/pull/293#issuecomment-606789989

[tesla809]

Any progress on this?

[timcash]

Firebase has some interesting ACL ideas for document style data. https://firebase.google.com/docs/reference/security/database

[jsonsivar]

That JSON ACL doc structure looks good :+1: Just also wanted to put collection and record level ACL on the radar. @andrewxhill did mention that would be a second release on ACL but chiming in here as well. It would be nice to make it so that for example a group of users can all ready the data in a thread or collection (done by your read permission above), but also that only the user that created the record can edit or delete that particular record.

Does the caller control the associated private key?

Is there a way to verify this already locally (different from the API key context creation for the hub)? Think I heard someone mention that but can't find it in the docs.