Refactor error handling in manage_via_mr.vue component

Previously, a new utility to handle API errors has been introduced in Enhance Security Configuration Error Handling i... (!112193 - merged) to be able to parse the error objects and extract the eventual user-facing errors to output to the user.

As the next step, the utility has been refactored in Refactored the error message parser in frontend (!115061 - merged) but with that, it introduced an unexpected side-effect of the utility with constructing the user-facing error using the same pattern already on the frontend. This should be considered an antipattern and this issue is aimed at finding a better solution.

Possible solution

Figure out what are the odds of an error object, returned from the apollo mutation not having both errors, and successPath. If such scenario is impossible, the if (!successPath) branch of the code can be remove because it won't ever be executed.

In this case, we still have to be able to provide a meaningful error message to the users, incl. the scenario where successPath is not available. This should be achieved by sending the correct user-facing error as part of the error object from the mutation.