Pad vbmeta images during cvd fetch

[3405691582]

The guest reads the vbmeta images with libavb, which expects to be able to read the maximum vbmeta size, so we pad the images in place to match this or the read will fail.

This implies that the image location must be writable, which is problematic for particular use-cases. It is worthwhile noting that images are also modified during cvd fetch to de-sparse images before the images are quiescent on disk. While this change does not alleviate the need for in-place image modification, it does ensure that the images need not be modifiable after the cvd fetch occurs.

assemble_cvd behavior is unchanged -- indeed it must not change, since it will need to operate correctly on images not sourced from cvd fetch.

[Databean]

Not a huge fan of extra behavior for specific filenames, but this does look like the simplest change.

The vbmeta_system call at least is made explicitly

android-cuttlefish/base/cvd/cuttlefish/host/commands/cvd/fetch/fetch_cvd.cc

Lines 286 to 295 in 01a5427

	static constexpr std::string_view kSystemImageFiles[] = {
	"init_boot", "product", "pvmfw", "system_ext", "vbmeta_system",
	};
	for (std::string_view system_image : kSystemImageFiles) {
	std::string member = fmt::format("IMAGES/{}.img", system_image);
	std::string rename_to = fmt::format("{}.img", system_image);
	if (!target_files.ExtractOneTo(member, rename_to).has_value()) {
	VLOG(0) << "Failed to extract " << member;
	}
	}

but the other case is buried inside ExtractAll.

What do you think of changing ExtractAll to return the paths of extracted files, so that fetch_cvd.cc can do postprocessing like padding?