About Defintion of Done

My opinion in order of bullets.

• Yes if the circumstances warrant and the entire Scrum agrees to the changes.
• No
• Absolutely, positively YES!!

Why doesn't the PO have the commitment, courage, focus, openness and respect (Scrum Values) to bring this up directly to the Development Team?  

A Sprint is intended to provide a potentially releasable increment.  The PO ultimately decides when the increment is ready to be released.  In this case the increment is "potentially releasable" but the decision is not to do so. The PO should be raising the issue with the Development Team, stories should be created to address the performance issues so that they can be refined and executed in a Sprint to improve the potentiality of the increment being released.

• Yes if the circumstances warrant and the entire Scrum agrees to the changes.

But If you change the DoD during Sprint you can be impact the Sprint Goal because you will have to test new constraints (defined in new DoD) in all items in Sprint and solve the performance problems too.

Another question about DoD. Can you add SLAs on the DoD?

But If you change the DoD during Sprint you can be impact the Sprint Goal because you will have to test new constraints (defined in new DoD) in all items in Sprint and solve the performance problems too.

During the Sprint, no changes are made that would endanger the Sprint Goal. However, discoveries may be made which indicate that the Sprint Goal no longer remains viable. This may include a discovery that the Definition of Done is no longer adequate. From your reading of the Scrum Guide, what do you think a team should then do?

Another question about DoD. Can you add SLAs on the DoD?

If they help to describe the standard that must be met for an increment to be of release quality, can you think of a reason why they ought to be excluded?

I think you should give us an idea of what exactly would need to be changed in the DoD. Could changes to the DoD endanger the Sprint Goal? Of Course. On the flip side, plenty of changes can be made to the DoD and have little to no impact on the current Sprint Goal. Your question is a good question but without better details, we really cannot help much.

But If you change the DoD during Sprint you can be impact the Sprint Goal because you will have to test new constraints (defined in new DoD) in all items in Sprint and solve the performance problems too.

Yes, that is a potential outcome. There is nothing mentioned in the Scrum Guide that even hints that there is a time and place for updating the DoD.  As @Ian pointed out you should not do anything during a Sprint that endangers the Sprint Goal.  But if a change to the DoD can be made without endangering the accomplishment of that goal, everyone agrees it is warranted, and everyone agrees it should be done, why delay it? 

The key to my answer was everything after the word "Yes".  It should not be done frivolously and without full consideration. 

One more thing I'll point out.  The DoD is not for each item in the Sprint Backlog.  It applies to the potentially usable increment being produced in the Sprint. So, there may not be a need to test "all items in the Sprint" if those items combine to make up the increment.  There is only need to test the entire increment to ensure it meets the DoD.

 There is nothing mentioned in the Scrum Guide that even hints that there is a time and place for updating the DoD.

Well, there is this:

During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of "Done", if appropriate and not in conflict with product or organizational standards.

It doesn't say the DoD should only be changed in the Retro, but it certainly implies that the Retro is a forum to discuss changes to the DoD.

That being said, I concur with the others here: A change to the DoD may endager the Sprint Goal. However, if the performance problems have a high enough impact, it's worth examining whether the Sprint Goal is still valid.

One risk of changing the definition of "Done" mid-Sprint is that there could be reduced transparency about the quality being delivered.

There should be a "Done" increment by the end of the Sprint. If there is an in-progress increment at the point that the definition of "Done" is changed, it could render that increment "not Done" until the increased quality expectations are met.

Depending on the amount of flexibility provided by the Sprint Goal, the Development Team may see opportunities to increase quality without endangering the Sprint Goal.