The Sprint Review should never be considered a gate to releasing value

does it implies the possibility to get end user feedback so we can discuss with stakeholders what feedbacks can be taken as priority for next sprint ?

You might even get feedback and adjust priorities before the end of the current Sprint. This could then allow the Sprint Goal to be better met.

or each increment if 'Done' will be demonstrated to stakeholders in mid of sprint itself before it gets released ?

Perhaps the best way to get feedback mid-Sprint would be to release work as soon as it is Done. By definition, Done work ought to be immediately usable and of release quality.

Although the sprint review is where the stakeholders most participate in, they also interact with the PO when discussing product value whenever the PO sees fit, and can also interact with the Developers whenever they need further information whilst working on a PBI. 

As an increment is born as soon as a PBI has met the sprints DoD, and as an increment must be in a releasable state due to it being compliant with the DoD, the PO can decide to release the increment at anytime during the sprint. 

My understanding is that one of the motivating factors behind putting an explicit statement that the Sprint Review is not a gate to releasing value came from the software community, who was trying to reconcile the Sprint Review with the practice of Continuous Deployment, where the software may be released as frequently as many times per day. However, this may also be applicable to any environment where a useable Increment may be turned over to stakeholders at any point in time. The intention is to say that at least one Increment is delivered to stakeholders at some point in the Sprint, and it may be before the Sprint Review happens.

In the case where you do have multiple releases of Increments, there is nothing that says that you can't get feedback or discuss with stakeholders. I'd even suggest that if you are releasing frequently, it's very important that the Product Owner have these discussions with stakeholders. However, I'm not sure that it makes sense to involve the whole team, that it's necessary to have these intermediate events, or that the Sprint Review can be replaced entirely.

Involving the whole team, or even subsets of the team, in frequent discussions and demonstrations with stakeholders takes the team away from their other work. Primarily, the "other work" is progress toward the Sprint Goal, but it also includes refinement and any other non-product work that they need to do. In other words, it can decrease the overall effectiveness of the team.

It may also not be necessary. The users and key stakeholders are probably busy people. One of the factors to consider when selecting a Sprint length is the ability to synchronize with these key stakeholders at the Sprint Review. Even if you're releasing more often than toward the end of a Sprint, the people who you would discuss the changes with or demonstrate the changes to may not be available more frequently.

Finally, if you end up changing the fundamental artifacts, events, and roles in Scrum, you no longer have Scrum. There's nothing wrong with not having or using Scrum and it may work for you. However, there are good reasons to set aside a specific, regular event for synchronization between the Scrum Team and key stakeholders. That event is the Sprint Review. Dropping definitely leads to a "not Scrum" situation and the team would need to mitigate the risks associated with losing this synchronization period in some other way.

In short, there's nothing stopping you from reviewing more frequently than once a Sprint. There's also nothing stopping you from reviewing less frequently. It's all about balancing risks and trade-offs. Scrum's solution is that regardless of release frequency, there is a synchronization period once per Sprint and this tends to work well for a lot of teams in a lot of contexts.