Give Troubleshooters read permission in the root

[labkey-adam]

Rationale

TroubleshooterRole doesn't grant read permissions in the root. This causes multiple problems, particularly viewing admin queries in the root and interacting with those grids. This change gives the role read permission restricted to the root. More details: https://github.com/LabKey/internal-issues/issues/785

Separate, but related, many SecurityPolicy methods iterate policy assignments associated with a set of principals, populate those roles or permissions into a HashSet, and return the set... only for all callers to immediately convert the set to a stream or simply test for the existence of a single role or permission. Reworking these key methods to return streams provides convenience and avoids creating, populating, discarding, and garbage collecting unnecessary collections, buckets, etc. in these frequently used code paths. It also allows for short-circuiting in the existence cases, since the iteration process can cease as soon as the desired role or permission is seen.

Some changes worth noting:

• Unlike the sets that had previously been returned, the streams now returned from SecurityPolicy methods may include duplicate roles or permission classes. Most callers shouldn't care, since they typically perform existence checks. Callers that require distinct sets (e.g., those that serialize the streams to JSON for API purposes) should invoke distinct() on the stream or collect to a set.
• I removed ImpersonationContext.getSiteRoles() since it wasn't useful and it was implemented inconsistently across the subclasses. I left User.getSiteRoles() in place, primarily used by tests. Instead of delegating to the ImpersonationContext method(s), it now simply filters the assigned roles via instanceof AbstractRootContainerRole. This simplifies the logic and increases consistency. For example, previously, an ElevatedUser that was programmatically assigned a site role would return an empty set from getSiteRoles(); now, it correctly returns the assigned site role.
• User and Group getGroups() are now marked as @Transient. There's no reason for ObjectFactory to invoke this method. Doing so is wasted effort, but, more importantly, it can end up caching bogus group information. For example, when inserting a new group into the database, userId is 0 at the point the method is called, thereby caching the wrong set of groups for the Guest user.