feat(search): search access controls

[david-leifker]

Introduces controls around search results based on policy privileges which can filter or restrict the data on the entities being returned from search operations.

Policy Logic:

• Support for user/group/ownership (including typed)/tags/domain/urn/domain policies
• new VIEW_ENTITY privilege
• Policy filters and restricting aspects on entities is located in the ESAccessControlUtil class.

OperationContext:

• Access policies must be pushed down from the initial request via (graphql, rest.li, openapi) all the way down to the query/dao layers within the project. This was implemented by introducing the concept of an OperationContext which wraps several layers of context including the session and system authentication contexts. Additionally it includes all information needed to build search query filters from policies for the user.
• The OperationContext also include the logic to compute a unique context id which should be added to all cache keys to ensure the cache doesn't bypass the intended filtering/restrictions.
• The OperationContext allows control over privilege escalation. The default implementation here follows the legacy mode where a user session is allowed to escalate to a system level privilege as needed. In the future this could be restricted to only allow escalation based on policy.

SearchFlags/SearchEntity:

• A new option was added to SearchFlags to indicate whether the result should filter or restrict content in the response entities.
• While extending the SearchFlags, also added the option to return soft deleted entities.
• The SearchEntity object within the SearchResult objects now includes a list of restricted aspects. The initial implementation only includes the key aspect which indicates that the entity should be fully restricted. In the future this might be a subset of the aspects for the entity.

Data Models:

• The Ownership model was extended to include ownership type information to be able to filter by ownership type. The data is populated with a mutation hook and not required to be populated by ingestion.
• Added new FieldType for MAP_ARRAY for maps with string keys and multiple values (without having to be string encoded)
• Updated ES mappings to ignore the dynamic schema created by MAP_ARRAY fields

TODO:

• ownership migration upgrade step
• complete unit tests for access controls
• comprehensive api support for openapi/rest.li/graphl
• restricted entity hydration and graphql response

Checklist

• The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
• Links to related issues (if applicable)
• Tests for the changes have been added/updated (if applicable)
• Docs related to the changes have been added/updated (if applicable). If a new feature has been added a Usage Guide has been added for the same.
• For any breaking change/potential downtime/deprecation/big changes an entry has been made in Updating DataHub

[david-leifker]

Note that I've found a critical limitation in this implementation. I've introduced a limit to the number owners by making the owner a nested field. This should be addressed by making the field the owner type instead. This reversal puts the limit on the max number of ownership types instead of the owner identities.

[david-leifker]

Fixed the owner urn limitation by using this structure

  "ownerTypes": {
    "urn:li:ownershipType:__system__none": [
      "urn:li:corpuser:jdoe",
      "urn:li:corpuser:datahub"
    ],
    "urn:li:ownershipType:__system__technical_owner": [
      "urn:li:corpuser:myuser"
    ],
    "urn:li:ownershipType:__system__business_owner": [
      "urn:li:corpuser:myuser"
    ]
  },

[chriscollins3456]

this is looking awesome. but man there's lots of code haha so it's kind of hard to get a very solid review. I left a few comments on higher level stuff but in general looking good.