From the Scrum Guide: 

>During the Sprint:
>
> 1. No changes are made that would endanger the Sprint Goal; 
> 2. Quality goals do not decrease; and,
> 3. **Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.**

The changes you mention fall into the last category, unless they endanger reaching the sprint goal. If the last story you're proposing to drop is the least important, chances are lower that it endangers the sprint goal.

If this happens frequently, spend a retrospective or two to find out how you could prevent this. Are you taking on too much work at the start of the sprint to begin with? Is the team in need of training?  Was there too much stuff unclear when the work started? (be careful to not start doing full waterfall analysis though!).

Your burndown will now reflect the new situation and should now show that you're  again on track for timely delivery of the new scope. Remember that the Burndown is a practice the team can use to see if they're still on track to deliver what they forecasted. If they do a new forecast (i.e. renegotiate scope), then the burndown will reflect the new status. If the Burn down is used for other purposes than the team's  internal progress tracking, then the sudden drop may need to be explained. As Scrum trainers, we generally caution against sharing the burndown as an official report at the end of the sprint. That's not its purpose and can lead to people making incorrect assumptions.

You mention a Sprint Review Report. This is not an official scrum artefact, so I can't tell an official story about how it should be influenced. It sounds like a report from the Product owner to the stakeholders. If the Product owner previously communicated the forecast by the team, then it may explain that certain features were not delivered. But during the Sprint Review meeting you'd indeed show that all you've delivered is green (Done according to the DoD). What will also be visible is that your velocity will be lower than usual, which may trigger some questions.

The Scrum master should ensure that the development team looks at the underlying cause that caused this change to happen. The natural point in time to do so is at the Retrospective. Be wary that the team simply reduces its forecast or creates a long list they may call a "definition of ready". It's better when the team tries to apply automation to reduce overhead of testing and deployment and when the team has more frequent communications about the real intent of the PBI so that they better understand it.