Description
This PR fixes a NullPointerException due to a missing null check in SamPermissionsImpl.canDoAction. The exception is thrown when an unauthenticated request is made to the Zip generation endpoint for an unpublished HOSTED workflow. We get there because WorkflowResource overrides canRead to add the permissionsImpl (SAM) checks, wherein the flaw is located.

Note that you can't reproduce this on qa, and that the problem only happens for HOSTED workflows.

How did the user trigger this? Per the logs, my best theory is that the user had copied the download link from the UI, and, days later, pasted it into their browser. We can tell that the user wasn't using the dockstore UI when the 500 occurred, because in the logged diagnostic info, the x-session-id-fingerprint is null.

I suspect that this PR also fixes https://ucsc-cgl.atlassian.net/browse/SEAB-6939

For some still-valid (IMHO) recommendations about the architecture of the auth code, see the longest paragraph in this PR description (of yore):
#4989

Review Instructions
On staging, via the API, try to download a Zip for an unpublished HOSTED workflow, as an unauthenticated user (no token), and confirm that you get a proper non-500 error response.

Issue
https://ucsc-cgl.atlassian.net/browse/SEAB-7134

Security and Privacy

If there are any concerns that require extra attention from the security team, highlight them here and check the box when complete.

• Security and Privacy assessed

e.g. Does this change...

• Any user data we collect, or data location?
• Access control, authentication or authorization?
• Encryption features?

Please make sure that you've checked the following before submitting your pull request. Thanks!

• Check that you pass the basic style checks and unit tests by running mvn clean install
• Ensure that the PR targets the correct branch. Check the milestone or fix version of the ticket.
• Follow the existing JPA patterns for queries, using named parameters, to avoid SQL injection
• If you are changing dependencies, check the Snyk status check or the dashboard to ensure you are not introducing new high/critical vulnerabilities
• Assume that inputs to the API can be malicious, and sanitize and/or check for Denial of Service type values, e.g., massive sizes
• Do not serve user-uploaded binary images through the Dockstore API
• Ensure that endpoints that only allow privileged access enforce that with the @RolesAllowed annotation
• Do not create cookies, although this may change in the future
• If this PR is for a user-facing feature, create and link a documentation ticket for this feature (usually in the same milestone as the linked issue). Style points if you create a documentation PR directly and link that instead.