Is it possible to make Scrum successful if any team member or team lead or product owner plays a role of scrum master?
There's a fine, and important line between can and should.
The Product Owner is the sole responsible individual for the product. They can delegate every responsibility and activity assigned to them; except the responsibility for the product.
The Scrum Master is responsible for knowing Scrum, facilitating meetings when needed, making sure those participating and interacting with the Scrum Team understand Scrum and the impact their interactions are having on the team, while protecting the team from reprisal.
In my estimation and experience, part of the job of both also includes getting the Development Team (those responsible for the manufacture of the product) eventually become so independent that both roles become obsolete.
There is no such thing as a "Team Lead" according to the Scrum Guide (as of this writing). Therefore, you can have one but, from a purely Scrum Guide perspective, they would be a Development Team member.
Anything is possible to be successful depending on the people involved. The question is whether it is Scrum or not. And then whether that is a good or bad thing:
Scrum is free and offered in this Guide. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
Having said all that. If you hear what is the "ideal"...no, you would not do that. Context switching between roles can become quite problematic. When I was the technical lead, the architect, and the Scrum Master for a team, we made an agreement that I would say from which perspective I was speaking whenever I spoke. I would even change my position in rooms based on the role I was embodying at the time. Scrum Master: Standing at the whiteboard, asking questions to help facilitate discussion. Tech lead or architect: I would sit at the table with the rest of the team. Eventually, the team picked up on this change without me having to make it explicit.
The concept of context/role switching is why we took the roles and responsibilities traditionally held by an individual and spread them across one PO, one SM, and roughly 7 other people. The PO is typically out and in (they come from the outside, the business and user world, into the Scrum Team). The SM is typically in and out (they from inside the Scrum Team to the outside world, to remove impediments, inform others on the impacts they are having on the team, and so on).
One of the problems you can find in teams is when the PO and SM are looked as managers. Because then the Development Team can begin to just give in to them. The way the practitioners with my organization talk about it is that SMs have influence but no authority. POs, ideally (from our experience) also have accountability but no autority.
What we mean by authority is that no one has a stick. They don't do employee appraisals. They don't have the ability to get anyone fired. None of that. So, from an organizational structure perspective, what you might end up with are functional managers (who are not on the Scrum Team); these would be things like the BA Functional Manager, they hold the "purse strings" to a vertical slice of the organization. The Scrum Team is a horizontal slice across the organization aggregating human resources in order to build a team with the skills and knowledge necessary to complete the backlog.
The question about combining the Product Owner and Scrum Master is a frequent one. It's been asked here on Project Management Stack Exchange and here (by me) on Software Engineering Stack Exchange. Mike Cohn also wrote a blog post on the subject. Although the things done by the Product Owner and Scrum Master are typically done by someone in a Project Management role in other process frameworks, there are advantages to splitting up the role. I think that a very skilled person may be able to be a Product Owner and Scrum Master, it's easier to ensure that all of the functions are being done at their peak by splitting them up to be done by two people. The Product Owner can focus on optimizing the product while the Scrum Master can concentrate on optimizing the team and process used to make the product.
As far as combining the Scrum Master and a manager role, I think that can be done. If you look at Disciplined Agile Delivery, the role of Team Lead encompasses the things usually done by a Scrum Master. This is a case where Scrum doesn't necessarily address organizational needs. Organizations often need managers and leads to grow teams (by being involved in recruiting and hiring efforts), perform strategic planning and roadmapping, and support career development of team members, and so on. Scrum does not address these concerns. As long as the team lead or manager is supporting a self-organized team and facilitates these things rather than taking on all of these themselves (except for maybe career development and 1:1s), I don't see this as a contradiction of the Scrum principles. However, if the team lead tries to direct the way the team works and doesn't facilitate learning and self-organization, that would go against the Scrum principles.
In both cases, your mileage may vary.
Until your organization and team understands the underpinnings of the agile methods (the Manifesto for Agile Software Development, the 12 Principles of Agile Software) and Scrum, I would want to stick as close as possible to a framework and then explore the things that are and aren't working. I want the Product Owner to be someone focused on the product, the Scrum Master to focus on the process, and the Team Lead to focus on the people (and, to be more faithful to Scrum, a member of the Development Team). The people in these roles should work together to maximize the effectiveness of the team, especially over time as the team and product change.
In my experience this role shouldn't be combined. There should be a person who looks over the team and their workload and a person who looks at what is the best for the product.
Also combining a productive lead, like a lead programmer, with a scrum master role takes away from both. That person will not have enough time to look after how the team is doing and how the code base is doing.