Do not read the on-disk inode in case of vnode allocation.

[fsu]

Test Plan

Typical fsx/fstorture tests to avoid regression.

[pfg]

Note why we specifically set ip->i_flags = 0 since r294652:

ext2: Initialize i_flag after allocation.

We use i_flag to carry some flags like IN_E4INDEX which newer
ext2fs variants uses internally.

fsck.ext3 rightfully complains after our implementation tags
non-directory inodes with INDEX_FL.

Initializing i_flag during allocation removes the noise factor
and quiets down fsck.

[fsu]

In D19327#413791, @pfg wrote:

Note why we specifically set ip->i_flags = 0 since r294652:

The ip->i_flags will be zero in all cases inside this function because we does not read new inode from disk at all for now and inode is allocated thru malloc with M_ZERO flag.

ext2: Initialize i_flag after allocation.

We use i_flag to carry some flags like IN_E4INDEX which newer
ext2fs variants uses internally.

fsck.ext3 rightfully complains after our implementation tags
non-directory inodes with INDEX_FL.

I think it was saved to disk by ext2fs somehow, and than fsck reported errors.
But, I checked it in the code and cannot understand how it could happen.
If I will reproduce this issue, it will be fixed immediately.

Initializing i_flag during allocation removes the noise factor
and quiets down fsck.

[pfg]

In D19327#414960, @fsu wrote:

In D19327#413791, @pfg wrote:

Note why we specifically set ip->i_flags = 0 since r294652:

The ip->i_flags will be zero in all cases inside this function because we does not read new inode from disk at all for now and inode is allocated thru malloc with M_ZERO flag.

OK, you are rught, we were not allocating (with M_ZERO) this before.