User testing - part of a sprint or not?

1. Meeting a true Definition of Done means that the item is production-ready.   Only items that are complete (meet DoD) should be presented in the Sprint Review.
   
   
   
   Can you envision a scenario where an item is ready for production, but still requires testing?
   
    
2. Is the item that the stakeholders identify a true defect (something not meeting the acceptance criteria of the story), or does it reflect missing acceptance criteria?   In my opinion, a story should not be rejected if it meets acceptance criteria.
   
   
   
   Considering the Product Owner should be the only one to close/accept items, does s/he still want to accept the story if a stakeholder identifies an error or something missing?
   
    
3. Stakeholders may be invited to the Sprint Review by the Product Owner, but their non-attendance should have no affect on whether a PO accepts or rejects an item.
   
   
   
   It is not a part of Scrum to hold up acceptance of sprint items because of stakeholder review.   The PO must be capable of accepting or rejecting team deliverables in a sprint, regardless of stakeholder involvement.
   
   
   
   If post-sprint stakeholder review uncovers issues, they should coordinate such findings with the PO, to potentially identify additional stories related to missing requirements or defects.
   
    
4. Once a story is accepted, it is closed.   It is a poor practice to re-open such stories post-sprint.   My suggestion would be to have the PO create a new story to address the incorrect requirement.

Should any testing happen before sprint Review?

If testing doesn't happen beforehand, should the increment really be considered "done" and fit for potential release?

What if during Review stakeholders point out a defect, do we still close the story or leave it open till it's fixed & accepted?

A user story is a place-holder for conversations about a requirement. If those conversations actually happened and the acceptance criteria for the story were subsequently met, then any further work will require conversations in a future sprint and one or more new stories to represent them. The old conversations and stories are over with and finished.

What if stakeholders invited by PO could not attend the Review & now asking for more time to check out the product during next sprint - is it common to close the story or leave it open till it's formally accepted? I know it's about DoD, so shall it be included there or not?

Why would stakeholders "formally" accept something? Can't the Product Owner represent their interests? Why can't the Development Team ensure that the increment is functioning correctly in the first place? The team should ensure it has the skills and resources to do so and to satisfy a release-quality Definition of Done.

What if the story has been accepted during Review, but a defect arrises in next sprints & it's related to an incorrect formula or logic requested by PO. Shall a PO create a defect or a new story for changing the logic?

The Product Owner may make a timely decision whether or not to release a "done" increment but that is not the same thing as accepting it. If any new work is discovered for a product which has met a "Definition of Done" then it should be accounted for on the Product Backlog. Whether it is called a story or a defect is immaterial.