Ok, let's get the misnomers out of the way.
You may very well be practicing all the scrum events, and holding true to those, but let's be clear:
Your team isn't agile at all. I'd dare say that your organization is not practicing the tenets of scrum, and that impedance mismatch (your dev team practicing scrum but the organization not respective the values) is what's causing your consternation (and the organization's, but one thing at a time).
Let's start with the softball:
last week Management came to us stating that developers can no longer participate in testing from the next sprint on, and that they need to focus on development activities or automation only (which they have never done before).
And let's see what the Scrum guide says about that, under the heading "The Scrum Team":
Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. (emphasis mine)
Later, under the subheading "The Development Team", the authors expand this principle:
They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
(again, emphasis mine)
Your next paragraph sheds further light on the issue:
Our team consists of 8 devs, 1 tester and 1 business analyst, so it's easy to tell that there is no human capacity to keep up with such code output rate.
If I told you that more code was worse for you than less code; what would you say? You'd probably look at me like I'm crazy, but there are two theses that support what I'm saying:
Does the 'code output' directly correlate into 'value that the customer needs right now'? Probably not, because even if it did; if the code doesn't work well and doesn't address all the ways in which it's used, it's not value, it's just a feature that's out there to tick a box. That may present value to sales; but in reality it's a liability built up for your development team over time.
There is an idea called "The theory of constraints", basically your whole team only moves as fast as its slowest link; and to improve that, you have to reduce the amount of work to whatever the slowest part of the process is. There's more to it than that, but that's the first step. Eli goldrait's "The Goal" as well as "The Phoenix Project" go deep into detail about this, and the Phoenix Project has the added bonus of being "The Goal" for technology teams.
Management's proposals included intercalating sprints by switching between coding and testing, so you can tell they are not getting the idea at all.
What would you do next if being in my shoes?
If I were in your shoes; I'd do the following:
Figure out what's actually bothering management. No, not getting code out is not bothering management -- they may think it is, but they're very likely wrong (see "The Goal" above as to an understanding why that is.
After finding out what really is bothering management (we need to make X widget sales this quarter; and the code is our first step to being able to make those sales), the team needs to reduce its workload (there are four types of work, Business Projects, unplanned work, Changes, and Operations projects (keep the lights on work, like updating a database, or upgrading a framework, or fixing auditing or logging, or improving observability) to match its constraints. Ultimately you need to identify the types of work the team does and ascertain what sort of work has the priority depending on the needs of the company (hint, unplanned work has a way of disrupting all the other types of work), and then the team can only take on as much work as they have the capacity to handle -- and that capacity is dictated by the constraint. In effect, you can only do as much work as you can test, or that your business analyst can analyze.
Overall though, I'd take a step back and ask why the organization thinks Scrum is the answer? It's clear management doesn't like the principles of scrum, so why do they think operating with a scrum team is the way to go?
Anyway, if you haven't already read those books, you should read them. They're good reads, and they'll change the way you think about work and give you actionable advice on how to solve the problems your team is facing; but they won't fix the culture of the company; that's up to you and the scrum master and your political capital to fix.