Allow querying/transacting as an identity via opts

[mpoffald]

Closes #409

This PR allows for querying/transacting as a given identity via opts, to get policy enforcement without directly invoking the top-level wrap-policy api fn.

Examples:

@(fluree/query db+policy {:select {'?s [:* {:ex/location [:*]}]}
                                       :where  [['?s :rdf/type :ex/User]]
                                       :opts {:did "did:fluree:Tf6i5oh2ssYNRpxxUM2zea1Yo7x4uRqyTeU"
                                              :role      :ex/userRole}})

or

@(fluree/stage db+policy {:id   :ex/widget
                          :schema/name "Widget2"}
                         {:did "did:fluree:Tf6i5oh2ssYNRpxxUM2zea1Yo7x4uRqyTeU"
                          :role      :ex/userRole})

This is supported in:

• query
• multi-query
• history query
• stage

Note that this leaves out some api fns that operate on dbs, eg:

• internal-id
• range
• slice

Also, the following are disallowed and will result in an error:

• wrapping a db in policy twice (eg passing in an identity in the opts and also using wrap-policy on the db itself)
• passing in an identity in the opts of an individual query in a multi-query (identity is only accepted on top-level opts in a multi-query)

Notes

• This just calls the underlying wrap-policy implementation under the hood, so the real change here was just to inspect the opts in all these fns and see if that needed to be done.
• We had discussed getting rid of the top-level wrap-policy api fn altogether, but ultimately I've left it intact for now. There's a whole test file for index-range that would need to be reworked to get index-range to work this way, and index-range was not in scope for this issue.

[mpoffald]

More details on how this PR handles these opts:

1. We do not look up roles for a given identity, it just works with what it's supplied (role lookups will be future work)
2. if you provide just a role, we allow whatever that role allows. If the policy cares about identity, we just won't let you do anything that requires a specific identity
   • Example: If there’s a policy that says “someone with :ex/userRole can see any :ex/user’s data but only their own ssn”, and you try to view all user data with just :ex/userRole, you will receive all the data that would’ve been viewable to anyone with :ex/userRole (no ssn’s at all, because you need identity for that).
3. providing just an identity is still not supported, if you don't supply a role we throw an error (see #1 above)
4. if you provide a role and and an identity, we just believe you that you want that identity to have that role for this operation and act accordingly

[zonotope]

📜