Introduce contextual view (drawer) to boards

Problem

We conducted validation (https://gitlab.com/gitlab-org/gitlab/-/issues/40988) that helped us understand that individuals would prefer viewing the work item detail contextually within a drawer instead of a modal. This issue introduces the contextual (drawer) view on issues and epic boards.

The feature is available behind :issues_list_drawer feature flag.

Proposal

Boards already leverages a drawer for additional details when selecting an item. Instead of having two versions of a contextual drawer view of work items in the product, we should update this to match the new experience.

1. [Requires Epics migration] Update the drawer on Epics boards
   We should update Epics boards first, as those will be migrated first to work items and can leverage the drawer without any issues.
2. [Requires Issues migration] Update the drawer on Issue boards Since Issues cannot yet be viewed in the work item layout (without UX problems), this change cannot be made until Issues have been migrated.

👀 Additional details

The below additional context has been copied from this thread:

@gweaver: how big of a lift would it be to combine opening work items from the list and board in the contextual drawer with the opt-in to the work item detail view?

@ntepluhina: TL;DR: around 3-5 points to implement POC on boards

Explanation:

The issue list has the drawer already behind the issues_list_drawer FF. It's not feature complete - we're missing at least design management and related merge requests, but the view is already there.

It wouldn't be much more complicated to add the same drawer to boards and replace the board sidebar with it. The main complexity would be reflecting the updates from the drawer on the board card. Both board sidebar and board lists operate with the same type (Issue or Epic). This allows Apollo Client to perform automatic updates on cards whenever we change issue properties in the sidebar. With the drawer, we will need to perform manual updates on the "active" board card since we will deal with different types. It's a temporary measure until we can fetch a list/board of work items, and mapping logic is rather cumbersome. Additionally, we would need to think about moving the card to a different list upon update (not sure it should be a part of the POC, we're not moving the cards now if I recall correctly).

On top of that, I believe we need a few UX changes to the drawer (making it wider maybe with 2-column view) but I defer this to @nickleonard

I would be happy to implement the drawer on boards with the same FF so we could have better idea what's missing.

@kushalpandya: Just went through the discussion, I agree that having a shared drawer implementation as Natalia mentioned is the way forward here (with complexity to be solved for Boards, and perhaps Roadmap in future), but in any case, we can approach it for Epics list (i.e. Work Item list in future) with the following strategy;

• The current version of the drawer (with limited metadata visibility) is available for OKRs and is behind issues_list_drawer FF.
• We can update the Epics list implementation first to use the Work Items object structure such that this drawer component can be triggered from this list as long as same FF is true (and may be move this drawer behind work_items_beta?).
  • We don't need to implement this list from scratch as the current Work Items list can be re-used with some Epic-specific changes.
• Since the frontend component within the drawer will be shared, any new feature added here will propagate in all its usages without additional work.

@ntepluhina: this sounds like a great plan 👍🏻 If we're able to move Epics list to use Work Items query, the complexity will be much lower comparing to the Issues list: we won't need any complicated manual cache updates like we're doing for issues

Requirements

• 🎨 Please find the detailed design requirements outlined here.