Adding new items to current sprint backlog during sprint

The Sprint Backlog can only be changed by the Developers.  That is their selected body of work that will allow them to achieve the Sprint Goal.  If something does need to be changed in order to achieve the Sprint Goal, the Developers can decide what changes.  Story Points are a poor way of deciding any of this.  They are only valid until work begins and only useful for Developers to estimate if something can be done within the Sprint timebox. After the Sprint starts, those points have served their purpose and are no longer relevant.  

If the practice is to change the Sprint Backlog because something has become more important, then I would suggest that you are changing the Sprint Goal and that the Sprint might be a candidate to be cancelled.  However, that should be a rare situation and taken as a last resort. The Product Owner is the one that choses to cancel a Sprint.  

Now, if I were in this situation, honestly I would let the Developers decide what to do and ignore the points.  If the Sprint is in progress, the Developers decide if the change in the Sprint Backlog can be accommodated within the remaining time of the Sprint timebox.

Sometimes we are used to add new items to our sprint backlog due there priority

Isn't the priority to meet the Sprint Goal? If not, why not?

This is rare. If this situation arises, I would suggest to call a meeting, discuss risks and then let Developer come up with their possibilities and capacity.

Hi, my question is not exactly on this subject, but related.

If a team completes all sprint planned work, have free time left in the sprint, but not enough to complete a task, what's the best advise from the team to follow?

Anything that Developers feel will help them become better at delivering usable valuable increments.  Things like Product Backlog Refinement, learning a new technology, updating tests, cleaning up their workspaces.  There is no limit to what they can do.  Remember that a Sprint is not about being busy every working hour during the timebox.  It is about accomplishing the Sprint Goal and delivering at least one usable increment of value.  After that is accomplished, the Developers can find things that will help them be better at doing that same thing again.

Thanks @Daniel.

Returning back to the poats question about sprint cancellation, when handling a single team, an something more important comes along, agreedif the sprint goal changes, the sprint is cancelled.

However in a multi-team environment where more that one team is acheiving different sprint goals during a sprint, if one team has higher priority work and their goal changed, should the sprint be cancelled and a new one started, if other teams are acheiving their sprint goal without any issues?

Each Scrum Team has their own Sprint.  They can be on the same cadence as other teams but there is not a single Sprint.  Even in scaled Scrum models there is not a concept of a single Sprint for multiple teams.  So, yes if one Scrum Team needs to cancel their Sprint because of a major event, then the other teams can keep right on going in their own Sprints.

Remember, that cancelling a Sprint is not something that should happen frequently.  If it is occurring often, then the Scrum Team should step back and take a deep look at the reasons for the cancellations.  There is mostly likely something wrong in the process that they are using to refine stories or in the way that the Product Owner is interacting with the stakeholders to understand their needs.