[UX] Consolidated plan items list page

Summary

The goal of this work is to define our transition away from having separate list pages for work items (Epics vs Issues) and into a single list experience. This makes it easier for users to manage their work, instead of needing to manage multiple lists that aren't connected. This also paves the way for future improvements that we have planned for the list page such as a nested hierarchy.

Proposal

Consolidate the existing Issues list (/issues) and Epics list (/epics) to a shared Work items list (/work_items). At the project level, where Epics do not yet exist, the Issues list will also be renamed to Work items.

In addition, we will be introducing some other changes to solve current UX concerns and set us up for some of the future work around Saved Views. This includes eliminating the current State (open/closed/all) Tabs in favor of a filter, as well as relocating the result count to be below the filter criteria.

With consolidating Epic and Issue items, we will also need to take into account how that can effect things like bulk editing from the list page, as certain fields/attributes are not shared across these types.

Acceptance criteria

Navigation changes (Approved by Foundations ✅)

At the group level, the Epics and Issues navigation items will be consolidated to Work items
At the project level, the Issues navigation item will be renamed to Work items
We will not include the count of total work items next to the navigation item at this time. This may change later based on feedback.
For users who have Pinned the legacy navigation items (either Issues or Epics), we will automatically Pin the new Work items navigation item for them.

Path changes

With the above navigation changes, the path for the new Work items list will be /work_items
Epic detail pages will no longer follow the /epics/IID pattern, but instead use /work_items/IID
Issue (and Incident) detail pages will no longer follow the /issues/IID pattern, but instead use /work_items/IID
- Other WITs (such as Tasks and OKRs) already use the /work_items/ path
With these path changes, we need to ensure there are redirects in place for the old paths (#513115 (closed) - list pages, #579837 (closed) - detail pages)

Breadcrumbs changes

On the new Work items list page, the breadcrumb should now use Work items instead of Issues or Epics.
On Epic detail pages, the breadcrumb should now use Work items instead of Epics
On Issue detail pages (and Incidents), the breadcrumb should now use Work items instead of Issues (#579638 (closed))
On OKRs and Task detail pages, the breadcrumb should also use Work items instead of Issues

Global "Create new" flow (top of left nav)

Create form

Add the Group/Project (namespace) selector as the first field
- Defaulted to current namespace
- Available options would be limited to namespaces within the root group
Add the Type selector
- Options available would be based on namespace selected (#517558 (closed))
- Default selection to the last used (if available). Otherwise default to Epic type when a group namespace is selected, and Issue type when a project namespace selected. (#517559)

New item button (top of list)

Rename the existing New issue / New Epic button to New item, which opens the create form modal
If current namespace is a Group: Group/Project (namespace) selector should be the first field in the modal
- Defaulted to the current namespace
- Available options would be limited to namespaces within the root group
If current namespace is a Project: Do not show the Group/Project (namespace) selector.
- New item must be added to the current project, thus this is the default namespace (though it isn't shown in the form as it isn't needed)
Type selector should be the second field in the modal
- Options available would be based on namespace selected (#517558 (closed))
- Default selection to the last used (if available). Otherwise default to Epic type when a group namespace is selected, and Issue type when a project namespace selected. (#517559)

Changes to `State` filtering

The current Tabs for State (open/closed/all) should be removed in favor of a new filter option in the filter bar.
The new filter within the filter bar should be named State, using the issue-open-m icon within the dropdown.
Options for the State filter should include Open, Closed, and Any (Any being separated in the options at the top similar to other filters such as Label)
The List page by default should include the State filter, set to Open (matching our current experience where we default to the Open tab)

Type filtering

Users will be able to filter by various types using the Type filter (which has already been present on Issues list)
- Allows users to create the same types of views they previously were able to with the Issues/Epics lists, while now allowing Epics to be combined with the other types.
- Allow multiple Type selections using the OR operator (#548480 (closed))

Sticky header

The row containing the filter bar and display options should be sticky during vertical scrolling, as seen in this prototype. (#579975 (closed))
- Only apply the sticky header on medium viewport and larger.

Results count

We will show the results count below the filter bar (above result items)
- This count will be based only on the results of the filters/query, meaning you will no longer see counts for all States like seen today in the Tabs.

Results

At the group level, results will now combine Epics and Issues (as well as other types already combined today on Issues).
There is no additional weighting or sorting for the different work item types, and would follow the sort criteria defined in the sort setting.

Sorting

The sort options available should be a combination of what is seen in the Epics list and Issues list today
- Essentially, it would be the Issues list options with the addition of Start date and Due date which is only on Epics today.
If a sort option doesn't apply to a work item type, those items would be at the end of the list and sorted by a default method (it looks like today this is by IID in descending order)

Filtering

When filtering by criteria that doesn’t apply to a certain type (ex: Iteration with Epics in listing), those types should not appear after filtering since they don’t meet/have the criteria (#580269 - followup for later, not GA)

Bulk Editing

When selecting items to bulk edit, only display bulk edit options in the sidebar that are common for all of the selected items
- (ex: "Color" would not be available when an Epic and an Issue are both selected – since it is only an Epic attribute).

List actions

-------------------------------

Related changes – can be broken out

Group-level settings (Settings > Issues) - #580271

Update the nav item from Issues to Work items
Update the page title from Issues to Work items

Project-level settings (Settings > General > Visibility) - #580271

Rename Issues to Work items
Update the description text based on proposed improvements
- Current: Flexible tool to collaboratively develop ideas and plan work in this project. Learn more.
- New: Plan and track work with flexible objects and views. Learn more.
Update where the Learn more link directs: https://docs.gitlab.com/user/work_items/

"Assigned issues" changes (nav shortcut and page in "Your work") - #580272

Rename the nav shortcut be "Assigned work items" (tooltip and aria label)
Update the nav shortcut to use the work items icon
Rename the Issues page in "Your work" to Work items (nav item and page heading)

Milestone report (#537770 (closed))

Update the list headers (underneath Tabs) to use the work-items icon rather than the issues icon.
Update the links that navigate to the list page to use the work items list
- In the right sidebar the links for "Open" & "Closed" (under Work items) should navigate to the work item list (and use associated filters).
- When items within "Work items" Tab is greater than 500, the alert we show which includes a "View all" link should go to the work item list.