Impersonating Troubleshooters can now impersonate users and groups

[labkey-adam]

Rationale

Backport of #7465

[labkey-jeckels]

The PR in develop is causing a crawler failure when it hits /home/user-impersonateUser.view with a GET. It's because ImpersonateApiAction.checkPermissions() doesn't always call super.checkPermissions(). That eventually calls PermissionCheckableAction._checkActionPermissions() which also checks the HTTP method. Without rejecting GETs via BadRequestException, we later hit the assertion in MutatingApiAction.handleGet().

https://teamcity.labkey.org/buildConfiguration/bt401/3887325?buildTab=tests&expandedTest=build%3A%28id%3A3887325%29%2Cid%3A2000000400&logFilter=debug&logView=flowAware

Simple repro is to hit /home/user-impersonateUser.view with a GET in your browser. We want to see:

{
  "exception" : "Method Not Allowed: GET",
  "success" : false
}

instead of:

{
  "exception" : "Should not get here",
  "success" : false
}

I propose we fix in this PR and let it propagate into develop. Maybe by refactoring the method check in PermissionCheckableAction into a separate method that can be called in ImpersonateApiAction.checkPermissions()?

@labkey-adam @labkey-danield

[labkey-adam]

Yep, I'm aware and have a local fix

[labkey-adam]

The checkPermissions() override in ImpersonateApiAction was an early experiment that should have been removed when I changed the subclasses to @RequiresNoPermission, delegating permission checks to the impersonation contexts