First of all, I agree with Philip Kendall that none of the changes that you say you want to make are actually desirable. While bypassing the review process by making it optional might increase productivity in the short term, in the long run it's going to result in more bugs, messy and inconsistent code and other kinds of technical debt — precisely what code review is meant to prevent.
Also, to be frank, I'd suggest starting by letting go your ego and honestly considering whether at least a small part of the problem might lie with you. It's certainly possible that the code review process in your team is objectively painful and inefficient — but it's also possible that it's not that bad, and that you're simple making it painful by struggling against it and insisting on having things done your way.
In particular, based on what you wrote, I'm wondering if just maybe your long experience as a developer and as a team lead might be making you subconsciously reluctant to adapt to the practices of your new team and to accept suggestions from others with less "seniority", even if it's actually good (or at least not objectively bad) advice. Frankly, a lot of what you wrote sounds a lot like the (unfortunately all too common) case of a senior developer moving to a new team with a different culture and development practices, but insisting on doing things the way they're used to because "it's better and I'm senior so I know better". Which could even be objectively true in some cases, but fails to account for the not insignificant value of having the entire team be on the same wavelength and following the same practices, even if they're not perfectly optimal.
Fortunately, there's an effective (though not always easy) way to check for and deal with such issues: when you join a new team with an unfamiliar culture, open your mind, let go your pride and pretend you're a new junior developer for a while. Let the other members of your team teach you their way of working, even if you feel it's stupid and wrong and cannot possibly work. Accept all their corrections and advice, do things their way even if it feels inefficient. Learn to understand how they do things, and why they do it that way.
In a few months, you should be able to adapt to and begin to understand the new culture you've found yourself in. At that point, if you still feel that things could be improved, is when you should start offering suggestions. But you can't improve a process without first understanding the process, just like you can't really fix buggy code without first understanding what it's trying to do.
Also, just to be clear, even during the "adaptation phase" you don't have to turn off your brain, and your experience can still be a valuable asset. If you think that something could perhaps be done better, offer it as a suggestion. If you notice that a change suggested in code review would introduce a bug, point it out. But don't push your way of doing things, and certainly don't try to lean on your experience and seniority to intimidate others into accepting your suggestions. In this phase, you're the one who's trying to learn from the other members of your team, however much more junior they might be.
(By the way, this is also a great way to learn a new programming language with an unfamiliar paradigm: find a good comprehensive tutorial, temporarily put aside everything you already know about how things should be done and even what names they're called, and just learn to do everything exactly the way the tutorial tells you. Once you've learned that, only then start thinking about how to synthesize your new and old knowledge into an improved and consistent whole.)
As an addendum, let me elaborate on the point I tried to make above by responding specifically to some remarks from your question:
All that is very nice until you start getting pull requests that can not be approved in days with tens of comments each.
Is this really a problem? If the PR fixes an urgent bug in production, maybe it is. But if your code review and testing processes are working, such showstopper bugs should be rare. And hopefully in such cases you can successfully make an argument for pushing a quick stopgap fix now before taking the time to implement a cleaner and better long term fix.
In my opinion, there usually shouldn't be any problem with having a PR stay in code review for days (or even weeks!) while you work mainly on something else in the mean time. Sure, it means that you'll sometimes have to return to the PR to make and/or discuss suggested changes, but you don't have to do that instantly. Maybe consider setting aside a few hours for code review every morning or at the end of the day.
If your PRs never get approved, even after you've either made all the suggested changes or provided good reasons for any that you really feel shouldn't be made, then that is certainly a problem that you should take up with the team. In some cases, it may help to simply ping the reviewers in chat and ask them what they think still needs to be addressed before the PR is ready to be approved, and what they feel would be the best way to get it moving forward again. Besides hopefully getting you a clearer idea of what the blockage is, it also puts the ball in their court to be proactive and to suggest solutions instead of objections.
In addition when requests are done, the team does not focus on what is IMHO important (patterns, interfaces, encapsulation, layering, method signatures) but on small details.
That's a common issue with code review, and I feel it's to some extent unavoidable. Whenever one starts going over a bunch of code in detail, the first things that will jump out are the small issues: inconsistent indentation, confusing variable names, lack of
final, typos in comments, etc. One needs to get past those superficial things before one can really proceed to deeper levels of code review, such as checking the program logic and data flow for correctness and the code structure and interfaces for clarity and maintainability.
And since even the typos and other superficial issues are issues that could and should be fixed, why not note them in the review so that they can be fixed? It shouldn't take you more than a few minutes to fix such minor things, and the result is more consistent and readable code. That is, unless you insist on making it difficult and time-consuming by arguing about every single suggestion.
(Of course, there may be a problem if all the suggestions you receive in code review are about such minor superficial issues. But the solution to that problem isn't less code review, but rather more and better code review.)
Example: There is a code convention that methods doing things logically connected should be in close proximity to each other. But then if you actually require that the methods must be ordered by their chronological execution, that goes a bit further than the general rule.
Sure. Is there a good reason not to order the methods as suggested, though? If not, why not just make the change? It's just a few seconds of editing, after all — probably quicker and easier than arguing about it.
That's my one super secret trick for efficiently dealing with "trivial" code review suggestions: accept, apply and move on. Even if you secretly think that your way of writing it looked nicer.
Of course, if you can articulate a specific reason why you think that e.g. rearranging the methods makes the code harder to read or otherwise objectively worse, by all means say so. But arguing with code review suggestions should never be your first choice. Only do it if you feel that the cost (in your time and possibly in code quality) of just making the change exceeds the cost of arguing about it (in time, stress and distraction, for both you and all others involved).
No-one is just reasoning that if we in first place did not had 50 methods in same class, the positioning of the methods would possibly not matter that much.
Did you actually refactor the class in your PR to make it have fewer methods, though? I would guess not. Are you going to do that? If not, why complain about others at least trying to keep the methods in (some kind of a) consistent order — even if it's not the order you chose when you first added them?
Of course, you could also decide to go ahead and refactor the class to be smaller in the next iteration of your PR. And you teammates might even thank you for it, if it's currently as bad as you say it is. While you're at it, though, why not also arrange the remaining methods in the suggested order? Do you really have any reason, other than ego and/or laziness, not to do that?
Such heavy code review process in my opinon creates a hostile atmosphere where a newcomer feels simply bad.
That's possible. And if the team is treating newcomers in a hostile manner, whether intentionally or not, that's certainly something that should be addressed. (And you can do a lot about that yourself, even if you don't succeed in changing other people's attitudes, just by leading by example and personally maintaining a friendly, respectful and empowering attitude towards any new team members — whether junior or senior — in the future.)
But honestly, just going based on what you've written in your question (which is of course a very narrow and limited glimpse into a complex interpersonal situation), it's also possible that the only thing that's actually being hurt is your ego, and that the apparent hostility that you're experiencing is really just a case of your new teammates being less deferential and more open to giving (and receiving) criticism than what you're used to.
If (and I do stress the if here) that's the case, the best thing you can do is swallow your ego and accept your teammates' criticism and advice as it's intended — not as an insult or a humiliation, but simply as a sincere attempt to help you adapt to the processes and traditions of your new team and to improve the code that all of you share responsibility for.