A few questions from a beginner

Tom,

One of the 5 Scrum values is Focus.   Your inquiries are well-worded and well-intentioned; however, the scope of your post is too much.   It would have been better if you created a number of focused inquiries.

That said, I'll reply to your first 2 questions:

I have read that good teams have their user stories estimated  and acceptance criteria agreed on before Sprint planning. When should this estimation be done then if not during Sprint Planning?

Per Scrum Guide, item refinement between the Development Team and the Product Owner is an ongoing process, and should not consume more than 10% of a sprint.   In my experience, teams refine and estimate future items throughout the sprint at regularly-scheduled refinement sessions.   Keep in mind that item details and estimates are subject to change up to Sprint Planning.   

Sprint Planning is not intended to be a refinement session for work planned in the next sprint.

What if during planning poker there are 2 estimators with votes for lets say 5 and 13 can’t agree with each other? What value should be assigned to this story?

One of many skills that a Scrum Master needs to develop is around consensus-building.   Your scenario paints two Development Team members with very different views on item effort and complexity.   Perhaps each should offer their thoughts on how they arrived at their estimate?   Perhaps others in the team should also provide their input?   What, if anything, might one team member be considering that other team members aren't?

Try a few rounds of estimation if needed (hopefully, an exception rather than the norm).   See if your team can get to a difference between two values close to each other (5,8 or 8,13).   A popular practice is to select the higher estimate in these examples, to account for the "unknown" unknowns that may be present in the item.

When are US/tasks being transferred across board? During daily Scrum picked by the person who is speaking?

Shouldn't a board or other information radiator always tell the truth?

What happens if during the Sprint one or more dev team members unexpectedly will get sick or is clearly underperforming? What set of steps should be taken considering the Sprint goal and a threat the Goal will not be delivered?

The Sprint Goal ought to remain intact, and the team should replan its work so that the Goal can be achieved. How important do you therefore think it is for a team to track its progress during a Sprint and to understand the work remaining?

What happens if people have so much to say that the ceremonies tend to last more than prescribed time-box? What if some issues cannot be covered within 15 minutes Daily scrum? When should it be discussed considering its urgency? After daily Scrum? Or should the speaker be cut off after X mins of speaking and informed to keep it brief?

All the time employed by the development team on ceremonies is time not employed in building a product increment towards accomplishing the sprint goal. The scrum framework reserves some time for the scrum events though due to their importance on inspection and adaptation. The scrum master teaches the scrum team to keep the events within their time boxes. In so doing they improve focus on the ceremony's purpose and also reduce time waste. 

The daily scrum is the daily opportunity to inspect progress towards sprint goal. To maximize its benefits the team members focus on this sole purpose and go straight to the point with regards to the work done, work left, impediments, requests or needs for the next 24h.

From the scrum guide: "The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work." Once the relevant information has been shared by any team member the details can be discussed afterwards if needed. Communication is not banned out of the daily scrum time boundaries, but encouraged.

Is cutting off speakers the best way to teach your team to keep within the 15 timebox? There is no unique recipe for a scrum master to teach this to every single team since every single team responds differently.

Sprint. Dev team figures out they have bigger/smaller capacity during the sprint they thought they had during Sprint planning. Who informs Product Owner about it? What happens next?

The development team and product owner colaborate to adjust the work as more is learned throughout the sprint but considering that the sprint goal is not endangered and the quality goals remain at level. Therefore in common agreement they could drop some work off the sprint backlog, or add more work/items if they are able to commit to it.

Clariffication: When I say "could drop some work off the sprint backlog" I mean tasks/subtask, not sprint backlog items (SBI). SBIs must not be removed from the sprint backlog since they are part of the initial team forecast and need to be inspected at the end of the sprint despite their state. 

@Juan,

SBIs must not be removed from the sprint backlog since they are part of the initial team forecast 

This does not concur with what is stated in the Scrum Guide:

The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint... As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

@Timothy

As I understand it, each Sprint Backlog Item has some [tasks/work/plan] defined along with it. The development team can update, remove or add new of these tasks to/from it since they are the only ones that 'owns' the Sprint Backlog, and this truly complies with the scrum rules.

They can also add more product backlog items in the middle of the sprint along with their related work for example if they believe they can accomplish more this sprint, turning them into SBI's for the current sprint, however they cannot remove SBI's from the sprint backlog freely. What would happen if the team could remove SBI's from the sprint backlog at their will?

Therefore, to me:

As new work is required, the Development Team adds it to the Sprint Backlog

refers to SBI's and/or tasks/work/plan.

When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint.

"the plan" (tasks/work/plan) can be removed. I don't believe SBI's can also be removed solely by the development team. They could remove entire not-done SPI's at the end of a sprint, couldn't they?