Refactor and provide explanations for cluster access badges on home page, Project detail page, ProjectUser detail page

[matthew-li]

Description

**** Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. ****

• Added an info icon (i) next to the badges denoting a user's access to a particular project on the cluster.
  • These badges appear on the following pages:
    • Home page
    • Project detail page
    • ProjectUser detail page (accessible from the icon under the "Actions" tab on the Project detail page)
  • When hovering over the icon, a popup appears with explanatory text.
• Explicitly distinguished between two states (where previously only "No Access" existed):
  • "Denied", for users whose cluster access has been denied by admins.
  • "No Access", for users who have not requested access.
    • Example: PIs selected under a new project request are not always automatically granted cluster access, since they often do not need it.
• Consolidated HTML logic into templates:
  • For displaying the badges
  • For displaying the info icon and associated popup
• On the Project detail page, added an info icon to the "Project Access on Cluster" column.
• On the home page, modified how cluster access statuses and the cluster username are computed.

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

**** Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration. ****

• Create users with the various cluster access statuses and ensure that the appropriate badge and popup text appear across the three pages.
  • "Active": Most users are already in this state; no icon should appear.
  • "Pending - Add": Join a project or be added to it, but do not process the cluster access request.
  • "Pending - Remove": Request to remove a user from a project.
  • "Denied": Deny a user's cluster access request.
  • "No Access": Generate a new project request with a PI that is not the user making the request.

PR Self Evaluation

Strikethrough things that don’t make sense for your PR.

• My code follows the agreed upon best practices
• I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation (if needed)
• My changes generate no new warnings
• Any dependent changes have been merged and published in the appropriate modules
• I have performed a self-review of my own code

[helbashandy]

Looks good! I have few future suggestions and couple of clarifying questions.

• If possible, do not exceed the 72 chars limit on commits titles, it makes it easier in understanding changes. If more info in necessary, utilize a new line on the commit message.
• I noticed on the previous PRs that they were merged using a merge commit, which is okay, but also adds some unnecessary messiness when checking the history tree and commits log. So I'd suggest using the rebasing flow instead of the merge flow, as it makes the history super clean and easy to track, reference, etc. (Happy to pair on it if you haven't done this before)
• Ideally, after a review is done, squash the commits into a single commit that references the exact issue being fixed, or multiple commits if seen fit.
• Finally, I have couple of questions to make sure I bring your attention to:

On the PR description, it says:

Explicitly distinguished between two states (where previously only "No Access" existed):
"Denied", for users whose cluster access has been denied by admins.
"No Access", for users who have not requested access.
Example: PIs selected under a new project request are not always automatically granted cluster access, since they often do not need it.

1- This looks different the PR title, as my initial understanding that this is a benign refactor. Is there a newly introduced functionality vs refactor?

2- Given that there were some things that changed how they were computed, is there anything that verifies that there is no regression in the refactor?