Filter confidential epics

What does this MR do?

Updates EpicsFinder to consider epic's confidential attribute when listing accessible epics in the group and subgroups.

Related to #213075 (closed)

DB queries:

query which checks user's max member access in the group (this is an existing query, we just re-use it in epics finder now): https://explain.depesz.com/s/9PAs

SELECT
    "members".*
FROM
    "members"
    LEFT OUTER JOIN "users" ON "members"."user_id" = "users"."id"
WHERE
    "members"."type" = 'GroupMember'
    AND "members"."source_type" = 'Namespace'
    AND "users"."state" = 'active'
    AND "members"."requested_at" IS NULL
    AND "members"."source_id" = 9970
    AND "members"."user_id" = 1642716
ORDER BY
    "members"."access_level" DESC
LIMIT 1

query which gets all visible epics in the group and its related groups (subgroups by default) if user is not member of the group. The list of group IDs is used (we preload groups as part of group permission checking so no subquery is used).

warning: this checks epics only in group id 9970, if I try with a synthetic list of 9970's subgroups then the query is pretty similar - https://explain.depesz.com/s/9eae) but I don't have access to this. There is a significant difference between cold cache: https://explain.depesz.com/s/EaRa and warm cache: https://explain.depesz.com/s/6zgj

SELECT
    COUNT(*)
FROM
    "epics"
WHERE
    "epics"."group_id" IN (9970)
    AND ("epics"."confidential" != TRUE
        OR "epics"."confidential" = TRUE
        AND "epics"."group_id" IN (
            SELECT
                "members"."source_id"
            FROM
                "members"
            WHERE
                "members"."type" = 'GroupMember'
                AND "members"."source_type" = 'Namespace'
                AND "members"."source_id" IN (9970)
                AND "members"."user_id" = 1642716
                AND (members.access_level > 10)))
    AND "epics"."state_id" = 1

Related to #213075 (closed)

Screenshots

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• 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