I've spent the last year and a half working with over twenty teams that have faced very similar issues.
Over that time we've experimented with several techniques and found some that work well.
First off to answer you questions:
1- Yes, absolutely train support. This is the "Bill Gates Penny" problem. The developers are paid to create new functionality, not to fix minor issues. Always have the developers ask themselves "Can someone else do this?" If the answer is yes, then let them. Developers want people to trust them, they need to trust Support. Start slow, have support pair with a developer at first so the dev can review. Then move to Dev review and then move the Dev out of the process completely.
2- Only add something to the product backlog if it directly connects to the goals of the product. If the work is directly related to an existing feature, then add it to the backlog. If it is work required to support near term work, add it to the backlog. Defects found in production get added to the backlog, they impact the shipping product. If something does not contribute to the sprint goals or product goals, don't add it to the backlog.
3- No, don't add things mid-sprint. The one and only exception to this is mission critical. If you have a bug in production that is halting the service, drop everything and fix it. Otherwise, don't interrupt the sprint.
Here is what is working now for me:
1- Only Blocker bugs can interrupt the sprint. Blockers are specifically defined with an SLA from the support organization. Blockers are added into the sprint as work. However they are not estimated. They are not part of the sprint commit so velocity should go down when you work on them. If you're constantly having your sprint interrupted with production issues, then you likely have a bigger problem that needs to be addressed.
2- All requests go through the product owner. When someone comes to the team and says "Can you do X", the team member says "have you asked the product owner?" The product owner owns the business outcome of the team and needs to make these decisions.
3- Only sprint or product contributing go in the backlog. Everything else is an Impediment or Blocker. If a product manager asks you to come up with charts for his next presentation, that isn't part of your sprint goal. While it may need to be done, it is an impediment to your real goal.
4- Have an Impediments List: Very easy if using a physical task board, requires a little imagination if doing it all electronic. Next to the task board have a place for impediments. Anything the team is being asked to do that is not part of the sprint plan goes here. Impediments don't get estimates as they are impacting the actual team goals.
5- Change your Standup Questions: Mike Cohn had some great advice on this. He recommends to add "that contributed to the sprint goal" to the end of the three standup questions.
- "I did W yesterday, that contributed to the sprint goal."
- I plan to do X today, that will contribute to the sprint goal."
- However I'm working on Y and Z right now, which do not contribute to the sprint goal, so not sure I'll get Y done today."
With these rules and practices in place, the visibility of the interruptions becomes very clear. When someone wants non-sprint work done, you can start asking "Is it more important that this work?" When people ask "why are you not getting anything done?" you can show them the Impediments list and how it impacted the sprint.
You might also want to do a quick Multi-Tasking Myth Exercise. Here is one, however Google and find many more.