read allowed projects on endpoints in nodes.proto

[vjeffrey]

User Story

there's plenty of prior art for this, as we are already doing the work of reading allowed projects on the ingested nodes endpoint in automate (see "filterByProjects" func https://github.com/chef/automate/blob/master/components/compliance-service/api/reporting/server/server.go#L342)
on list endpoints, we need to filter by allowed projects
on update/delete endpoints, we need to ensure the user has update/delete rights on those resources/has the correct allowed projects

this work concerns the following endpoints in nodes.proto:

	rpc Read(Id) returns (Node) {};
	rpc Update(Node) returns (google.protobuf.Empty) {};
	rpc Delete(Id) returns (google.protobuf.Empty) {};
	rpc List(Query) returns (Nodes) {};
	rpc BulkDelete(Query) returns (BulkDeleteResponse) {};
	rpc BulkDeleteById(Ids) returns (BulkDeleteResponse) {};

Definition of Done

reading projects/adding to filters/etc on all above listed endpoints

[vjeffrey]

I believe reading allowed projects on list and read endpoints for the nodemanager nodes should be prioritized and included in the "GA" definition of iamv2 resource scoped access.
why?
b/c every ingested report sends information about itself to the nodemanager
this node information is available at api/v0/nodes/search
with #1772, we ensured that the nodemanager nodes' projects information is always up to date
without doing the work to read allowed projects on api/v0/nodes/search and api/v0/nodes/id/{id}, users who are not supposed to be allowed to see nodes x, y, will be able to see some metadata information about those nodes (last scan/run status, node name, other info)

this is a small amount of work. most of the work is testing.

[vjeffrey]

i'm gonna open a separate issue for just the list and read parts of this, since that is the part we need for the GA release. the other endpoints can wait.

[vjeffrey]

opened #1894 for this. after thinking about the scenario i also realized this is only necessary on the search endpoint