Change how direct vs indirect members are calculated

📖 What does this MR do?

Closes #300301 (closed)

Changes how direct vs indirect members (project and group) are calculated. Previously I was comparing member.source.id to sourceId on the frontend to determine if a member was direct or inherited. This worked for group members, but now I am working on converting the project members view from HAML to Vue and realized this technique won't work. The reason it won't work is because a project and a group could have the same ID so there could be an edge case where a member is inherited but displays as direct.

For example:

"Example Group" - ID 1
|
|-- "Example Project" - ID 1

If we add a member to "Example Group" they should be displayed under "Example Project" as inherited With the current implementation that member would be displayed as a direct member because the IDs are the same.

📋 Summary of changes

• Expose is_direct_member on app/serializers/member_entity.rb
• Update isDirectMember and other utils that rely on that function in app/assets/javascripts/members/utils.js
• Update relevant specs

💻 Local testing

1. Create a group
2. Navigate to Group -> Members

How to add a group

1. Navigate to Group -> Members
2. Click the Invite group tab

How to add an invited member

1. Navigate to Group -> Members
2. In the GitLab member or Email address field enter an email that a user does not already own
3. Click Invite "example@test.com" by email

How to request access to a group

1. Log in (or impersonate from admin dashboard) a user that doesn't already have access to the group
2. Navigate to the group overview
3. Click Request access located below the group name

🖼 Screenshots

No visual changes, screenshots below for extra context

Before	After

🚦 Does this MR meet the acceptance criteria?

Conformity

• [-] Changelog entry
  • Not needed, developer facing change
• [-] Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• [-] Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team