No understanding of management for agile development
This can probably be solved by handing the managers some basic information, e.g. link to agile manifesto and some blogs about the subject. They also have to understand that no process management format is a silver bullet. Neither agile, waterfall or whatever else you can come up with will automatically solve all problems. Ultimately the quality of the people involved determines that. And I mean quality in terms of role specific skills, but also soft skills.
A PO that does not teach management that you need more people and
capacity
Management may or may not be able to afford more resources. And the number of resources should only determine how fast a project can move, not how well it functions. So if they are happy with the speed then there should be no need to add more people.
An ambiguous view of the PO but also the agile departments.
Either role in a Scrum team should have a clear understanding of what their responsibilities are and what the other roles responsibilities are. If that is understood then there should be respect for the decisions each responsible person is taking for their role. Here is a brief rundown:
Product owner: Is ultimately responsible for the product. Hence she can determine what will be developed. But she is doing that through maintaining the product backlog list only.
Scrum Team / Scrum Master: The team is responsible to work on the highest priority topics from the product backlog. They are also responsible for determining how long development tasks take and for organizing the work in the team. Team members should all be technical and everyone should be able to fulfill development tasks. That includes testing and QA related tasks. Many organizations hire "testers" as a separate role from "developer" (often lesser paid) and that seems to be the case in your organization. From an actual agile team perspective that distinction should not be made and a developer should be able to write tests for the SW his team develops. Incentives should ideally be made to the whole team and not individual members. Scrum Master should ideally be a role that is passed to someone else every Sprint (underscores the fact that the development is a team effort).
The team is responsible to estimate their productivity and commit to a set of product backlog items to be developed during the next Sprint. The team should make their best effort and if they frequently miss their goals, then they are bad at estimating and should learn to improve.
A scrum team should not have more than 5-10 people. If it is larger it should be broken up into multiple teams.
Is the PO really always right?
See my previous point. He is always right when it comes to determining what are the priorities for items in the product backlog. This will determine what will be chosen for development in the next Sprint planning. He needs to be trusted in terms of those decisions, but he cannot be involved in determining development timelines or technical implementation decisions. He can only influence development by providing the right backlog items with descriptions for the next Sprint planning. He cannot influence development during a Sprint and he does not even need to be part of Sprint planning if the user stories in the backlog are well described.
Can the PO also decide to harm the team?
That is an absurd question and the answer should be obvious.
The retro does not work because there are no solutions. The other
major issues can not be solved.
The retrospective feedback should be mostly for the Scrum team internal organization, but if there are suggestions to management they should be documented and sent in written form to the responsible managers (with CC to upper managers if no reaction / response happens).
The team feels betrayed both by the PO and by the management. This
leads to angry reactions.
Fixing the teams feelings should be your first priority. Keep in mind that you absolutely have to trust the PO on his backlog decisions and on the other hand make sure he can trust the teams development estimations and results. If you are frustrated because of a lack of additional resources, then you should organize your scrum team differently. Have some of the developers help with testing tasks and make sure to include those efforts in Sprint planning. This will mean the team can develop less features in a Sprint but everyone will be more happy with the results.
Please note that it is very hard to fix a toxic workplace and it is only possible if everyone wants it to happen. If it happens to be the case because of toxic managers then there is nothing you can do but find another job.
In addition to actually reading the agile manifesto I recommend to watch pragmatic Dave's "Agile is Dead" speech or read his blog entry. With that and a little common sense there is probably no need for a Scrum trainer or consultant.