Bugfix: Don’t re-grab pointer/keyboard on MappingNotify (Thanks wilmer)

This fixes bug http://bugs.i3wm.org/545, where characters (of your password)
would rarely slip through when entering your password (especially) after
resuming your notebook from suspend to RAM.

The reason is that when resuming, X triggers one or more MappingNotify events.
At the same time, CPU load is high. This leads to a race-condition between the
ungrab and re-grab in which i3lock temporarily does not grab the keyboard.

One way to fix this is using xcb_grab_server() before and xcb_ungrab_server()
after the ungrab/re-grab. However, I think we actually don’t need to
ungrab/re-grab at all. I seem to have put that code in here by mistake – in i3,
we re-grab after MappingNotify, but there we only grab specific keys. In
i3lock, we grab the whole pointer/keyboard, so there should be no need.

If I’m incorrect and this breaks some subtle use-cases for people with strange
layout setup, at least we can properly document on why we need it, after we put
it back in ;).

i3lock.c

@@ -231,21 +231,14 @@ static void handle_visibility_notify(xcb_visibility_notify_event_t *event) {
 }
 
 /*
- * Called when the keyboard mapping changes. We update our symbols and re-grab
- * pointer/keyboard.
+ * Called when the keyboard mapping changes. We update our symbols.
  *
  */
 static void handle_mapping_notify(xcb_mapping_notify_event_t *event) {
     xcb_refresh_keyboard_mapping(symbols, event);
 
-    xcb_ungrab_pointer(conn, XCB_CURRENT_TIME);
-    xcb_ungrab_keyboard(conn, XCB_CURRENT_TIME);
-    grab_pointer_and_keyboard(conn, scr, cursor);
-
     modeswitchmask = get_mod_mask(conn, symbols, XK_Mode_switch);
     numlockmask = get_mod_mask(conn, symbols, XK_Num_Lock);
-
-    xcb_flush(conn);
 }
 
 /*