Add manual mount command option

[dwc0011]

Description

Create a user controlled custom "manual-mount-command" option that when present will run in place of the packer-plugin-azures's mount step, providing the user total control over partitioning and mounting process. Aligning the chroot builder with similar capabilities to the ebssurrogate builder, allowing for reuse of configs/scripts for each builder with minimal edits. While packer still manages the overall workflow around the interactions with the cloud apis and registering/creating images and abstracting that workflow across the different providers.

Use Case(s)

Allows users to use the chroot builder to create an image with an lvm-enabled root volume but also, instead of just targeting LVM, this is a flexible option that supports other complex mounting scenarios.

Much like the ebssurrogate builder supports total user control a "manual-mount-command" will bring this capability to the chroot builder.

We are also working to add this to the packer-plugin-amazon chroot builder to support issue: hashicorp/packer-plugin-amazon#602

Potential configuration

"manual-mount-command": when set, the built in mounting step is skipped and a new manual mount command step is performed instead. It is a string that represents the command(s) to run.

**Note: mount path and device are still processed in the manual step. If user wants to use the configured/detected devices/mount paths they can reference like the second example.

source "azure-chroot" "manual-mount-example" {
  from_scratch    = true
  ...
  manual_mount_command  = "chmod +x ./scripts/mount.sh && bash -x ./scripts/mount.sh"
}

source "azure-chroot" "manual-mount-device-example" {
  from_scratch    = true
  ...
  manual-mount-command="chmod +x ./scripts/mount.sh && export SOURCE_NAME_ENV='${source.name}' && export BUILD_DEVICE='{{ .Device }}' && bash -x ./scripts/mount.sh"
}

Resolved Issues

Closes #510

Rollback Plan

If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

None

[dwc0011]

@anurag5sh I wanted to see if you have time to review this PR and provide any input.
Thanks!

[tanmay-hc]

@dwc0011 Thank you for raising the PR, I think it would be a useful feature to have.
However, I feel instead of creating a new step altogether, can we update the current one, StepMountDevice instead, to handle both the cases, giving priority to ManualCommand and then to ManualOptions?

[dwc0011]

@dwc0011 Thank you for raising the PR, I think it would be a useful feature to have. However, I feel instead of creating a new step altogether, can we update the current one, StepMountDevice instead, to handle both the cases, giving priority to ManualCommand and then to ManualOptions?

I can certainly do that, I did it as a separate step because when I contributed to the amazon plugin a few years ago, they wanted what I had added a new step to not impact the current step in any way.

I will start work on switching into the mount step soon.

Thanks

[tanmay-hc]

@dwc0011 As I checked the changes shouldn't affect the current flow unless the user explicitly specifies this field.
Rest changes looks good. Please make the suggested change and I could take this change up in the upcoming release planned.

[dwc0011]

@dwc0011 As I checked the changes shouldn't affect the current flow unless the user explicitly specifies this field. Rest changes looks good. Please make the suggested change and I could take this change up in the upcoming release planned.

thank you @tanmay-hc I will work on it this week, we are doing some testing and I once complete I will refactor to include in the current step and get it pushed.

I appreciate your engagement and responses!