fsck.gfs2: Don't allocate leaf blocks in pass1
    
    Before this patch, if leaf blocks were found to be corrupt, pass1
    tried to fix them by allocating new leaf blocks in place of the bad
    ones. That's a bad idea, because pass1 populates the blockmap and
    sets the bitmap accordingly. In other words, it's dynamically changing.
    Say, for example, that you're checking a directory a dinode 0x1234, and
    it has a corrupt hash table, and needs new leaf blocks inserted.
    Now suppose you have a second directory that occurs later in the bitmap,
    say at block 0x2345, and it references leaf block 0x2346, but for some
    reason that block (0x2346) is improperly set to "free" in the bitmap.
    If pass1 goes out looking for a free block in order to allocate a new
    leaf for 0x1234, it will naturally find block 0x2346, because it's
    marked free. It writes a new leaf at that block and adds a new
    reference in the hash table of 0x1234. Later, when pass1 processes
    directory 0x2345, it discovers the reference to 0x2346. Not only has
    it wiped out the perfectly good leaf block, it has also created a
    duplicate block reference that it needs to sort out in pass1b, which
    will likely keep the replaced reference and throw the good one we
    had. Thus, we introduced corruption into the file system when we
    should have kept the only good reference to 0x2346 and fixed the
    bitmap.
    
    The solution provided by this patch is to simply zero out the bad
    hash table entries when pass1 comes across them. Later, when pass2
    discovers the zero leaf blocks, it can safely allocate new blocks
    (since pass1 synced the bitmap according to the blockmap) for the new
    leaf blocks and replace the zeros with valid block references.
    
    rhbz#902920