resize2fs: move bitmaps if shrinking would orphan them

It is possible to have a flex_bg filesystem with block groups
which have inode & block bitmaps at some point well past the
start of the group.

If an offline shrink puts the new size somewhere between
the start of the block group and the (old) location of
the bitmaps, they can be left beyond the end of the filesystem,
i.e. result in fs corruption.

Check each remaining block group for whether its bitmaps
are beyond the end of the new filesystem, and reallocate
them in a new location if needed.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
mke2fs: calculate journal blocks just after fs initialize

We can calculate journal blocks as soon as blocksize is set.
It will help to figure out wrong journal blocks count earlier.
This will save some un-necessary initialization.

Without patch output =>
mke2fs /dev/sdc1 -J size=1048576
mke2fs 1.42.7 (21-Jan-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
61312 inodes, 244936 blocks
12246 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=251658240
8 block groups
32768 blocks per group, 32768 fragments per group
7664 inodes per group
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376

Allocating group tables: done
Writing inode tables: done

The requested journal size is 268435456 blocks; it must be
between 1024 and 10240000 blocks.  Aborting.

With patch output =>
mke2fs /dev/sdc1 -J size=1048576
mke2fs 1.42.7 (21-Jan-2013)

The requested journal size is 268435456 blocks; it must be
between 1024 and 10240000 blocks.  Aborting.

Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Update release notes, etc., for final 1.42.8 release

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>