Unexpected behaviour with `promote_to` quick action

Summary

We introduced support for changing work item types with #385227 (closed) in %16.0 where user can use /type <type_name> to change a type of a work item, additionally, this feature was exposed on Tasks and Key Results via /promote_to via #412534 (closed) in %16.1 where user can promote a Task to an Issue or a Key Result to an Objective. However, there are bunch of problems with this behaviour;

• A record can only be promoted if it doesn't already have a parent, this limitation is not documented in https://docs.gitlab.com/ee/user/tasks.html#promote-a-task-to-an-issue.
• In case the user attempts to do such a promotion, it fails silently.
  • Interestingly, if /type issue is used instead of /promote_to issue on such a task, error shows up correctly, as implemented in !122489 (merged).
• If record doesn't have a parent and user tries to promote it, this works fine.
• When a task is successfully promoted to an issue, the user unfortunately stays on same page with promoted Issue (formerly a Task) showing up in Tasks-like UI, this is incorrect.

Possible solutions

Problem 1: When a parent is present, the promote quick action doesn't work

1. We show an error on UI when promotion fails and direct the user to de-parent the record and try again.
2. We hide /promote_to on records which have parent.

If the above solutions are not possible, we need to prevent users from changing the type of a Work Item (either by /type or by /promote_to) to any unsupported object, particularly legacy issues until issues are migrated to Work Items.

Problem 2: Newly created issue is displayed on the work items UI

1. We perform a page redirection in case promotion is successful (provided that /promote_to is only visible if it is eligible for a given task).
2. Show a success message with a link to the issue, the issue is then displayed in the correct UI format