Filter out epic's notes that can not be exported

What does this MR do and why?

Related to #384265 (closed)

When exporting a group that contains cross-group child epics (i.e. epics with children from different group hierarchies) they could include notes that are not visible to the user.

To be able to filter readable notes when exporting the group's resources, this MR introduces a new Exportable concern that can be included in the resource's model and provides authorization for the resource associations.

Important notes:

• The authorization relies on #readable_by? being defined for the association as well as the corresponding policy
• If special permission is required, #exportable_record? should be defined in the association's model. This method will take priority over #readable_by?.
• The change in behavior affects only resources that include Exportable and define #exportable_restricted_associations containing associations being exported (i.e. included in import_export.yml)
• The concern also provides the method #exportable_association? used for conditional export
• Cross-group epics feature is still in development and behind the feature flag :child_epics_from_different_hierarchies

Screenshots or screen recordings

Example epic with cross-group notes (exporting user has no access to External Group)

Exporting user view	External Group owner view

How to set up and validate locally

1. Enable the Feature Flag for cross-group child epics

   Feature.enable(:child_epics_from_different_hierarchies)

2. With a non-admin user (@user_a) create a group (My Group) and two epics (My Epic and My Child Epic)
3. With a different user (@user_b) create a new private group (External Group) with an epic (External Epic)
4. Add @user_b to My Group as Reporter
5. Signed in as @user_b visit My Epic and add External Epic as a child epic
6. Signed in as @user_a visit My Epic and add My Child Epic as a child epic, the current user should only see the system note mentioning My Child Epic
7. Visit the group settings http://gdk.test:3000/groups/my-group/-/edit and export the group in the Advanced section
8. Download the export file and find epics.ndjson inside tree > groups > 192 directory
9. Ensure the notes association contains only one note with the text "added epic \u00262 as child epic"

See example with json files exported before and after this change.

Tested Scenarios

With existing settings

1. Epic with an inaccessible parent
   • Only shows accessible notes
   • Does not include the parent field (due to conditional export)
2. Epic with an accessible parent
   • Shows the parent field
3. Epic with inaccessible child epic
   • Only shows accessible notes
4. Issue with inaccessible epic
   • Does not include the epic_issue field (due to conditional export)
5. Issue with accessible epic
   • Shows the epic_issue field

With hypothetical settings

Example 1: Conditionally export the field label_links for issues

When using an association that doesn’t have a policy we get an error that is sent by email:

Project Test Project couldn't be exported.

The errors we encountered were:

no policy for LabelLink

After adding a policy or defining exportable_record? in LabelLink:

1. Issue where all label_links are inaccessible
   • Does not include the field
2. Issue with accessible label_links
   • Includes the field
3. Issue with empty label_links
   • Include the field with value []

Example 2: make epic_issue a restricted association for issues (instead of a conditional one)

1. Issue with inaccessible epic_issue
   • Includes field and shows value nil
2. Issue with accessible epic_issue
   • Includes the field with the record
3. Issue with no epic_issue
   • Includes field and shows value nil

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.