fs_mgr: Revert "Try to recover corrupted ext4 /data with backup superblock"

This reverts commit 72abd7b2
(change Ia39af3340c0e241f62557b7c2cc8b800443342f9).

When vold enables either FDE or metadata encryption, it encrypts the
filesystem in-place.  Unfortunately, due to a bug, for ext4 filesystems
it hasn't been encrypting the backup superblocks.

Also, in read_ext4_superblock(), the check for
StartsWith(blk_device, "/dev/block/dm-") can return true even if the
encryption mapping hasn't been added yet, since when a GSI image is
booted the userdata block device is a logical volume using dm-linear.

The result is that read_ext4_superblock() can recognize a backup
superblock when the encryption mapping hasn't been added yet, causing
e2fsck to run without the encryption mapping and corrupt the filesystem.

https://android-review.googlesource.com/c/platform/system/vold/+/1385029
will fix this for new or factory-reset devices.  However, there probably
are many existing devices that already have their backup superblocks
unencrypted.  Therefore, the EncryptInPlace fix isn't enough and we have
to revert the change that started using the backup superblocks too.

Bug: 161871210
Bug: 162479411
Change-Id: I279f84c072bc6c8d3e251a5e95c78f8d6c0d50ba
Merged-In: I279f84c072bc6c8d3e251a5e95c78f8d6c0d50ba
(cherry picked from dc3e897a)