Ticket Lifecycle According to Scrum

Edit:

The other edge case that is bothering me, is tickets that have been done during the Sprint. Should they be removed from the Sprint Backlog after they are done/accepted by PO&customer or should they stay in the Sprint Backlog until the next Sprint is started?

What you are asking about is procedural.  Scrum does not provide process, it provides a framework.  Process is something that the people doing the work need to determine.  You need to discuss this with your Scrum Team to determine what makes the most sense for them.

I will give you my opinion though.  

I start with as few buckets as possible.  Product Backlog, Sprint Backlog, and Done are my standard starting points. Everything else is something might be useful.  And frequently the other buckets will come and go as the team determines the ultimate set.  To support my bare minimum use the Scrum Guide.  

The section that describes the Product Backlog is relatively short.  But note that it does not mention any kind of sub-categories.  Everything in the Product Backlog represents some change that is needed to the product.  "Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities."  The section that describes the Product Owners states 

The Product Owner is also accountable for effective Product Backlog management, which includes:

• Developing and explicitly communicating the Product Goal;

• Creating and clearly communicating Product Backlog items;

• Ordering Product Backlog items; and,

• Ensuring that the Product Backlog is transparent, visible and understood.

These lead me to believe that items that are "deemed ready for selection in a Sprint" would be ordered at the top of the backlog while those needed more attention are lower in the backlog.  

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

Notice that it does not state that they items in the Sprint Backlog no longer exist in the Product Backlog.  That is because they still represent work that needs to be done to the Product.  

I also want to point out that no where in the Scrum Guide does it refer to the "Done-log".  Again, because all of the items that reach Done are still representative of work that needed to be done for the Product, they would continue to live in the Product Backlog.  

Should they be removed from the Sprint Backlog after they are done/accepted by PO&customer or should they stay in the Sprint Backlog until the next Sprint is started?

The Sprint Backlog represents the Product Backlog items that can be Done by the Developers during a single Sprint.  Even if those items are Done, they still satisfy that statement.  So why would they be removed from the Sprint Backlog?  In fact, why would you ever remove an item from a Sprint Backlog, even when the Sprint has reached its end? Each Sprint Backlog is unique to a single Sprint and is still part of the Product Backlog so what purpose does it serve to remove them? 

Now one edge case is the "Needs Refinement". Should it be mutually exclusive with the "Product Backlog"?

Why would it be? The work on a Product Backlog is emergent for a complex product, and ought to be continually refined.

I imagine that a new ticket, especially if formulated by a customer, should be refined to a certain level before it should be put into the Product Backlog by the PO.

I'd suggest that the work ought to go on the Product Backlog if the PO thinks it's valuable, so it is transparent, and can then be refined.

The purpose of refinement is to make work ready for Sprint Planning, meaning it is easily selectable: the Developers understand it can be Done in a Sprint.