Adds initial support for login before bootstrapped build step

[jonathanmccormack]

This PR adds support for performing docker login before commencing the build step when bootstrapping a packer build using a Dockerfile. More specifically, these changes add analogous logic to the build step from the pull step to attempt to authenticate with the information specified in the login_server, login_username, and login_password config options when the login value is true, or via ECR when the ecr_login value is true. This allows the user to build images from a private docker repository when performing a bootstrapped build from a Dockerfile.

Closes #194

[lbajolet-hashicorp]

Hey @jonathanmccormack,

Thanks for the PR, as I mention in my comment, this should work but duplicates existing code, so I think we should probably reify that logic in a common area/package so the steps or other components that need it can use it instead of copy-pasting it when they want to use it.

That said, since the code is already duplicated, this can be done in a later PR, let me know what you prefer and we can roll with it.
Besides that, this looks good to me.

[lbajolet-hashicorp]

I'm assuming this code is quite similar, if not equivalent, to the code from step_pull.go, is that right?
If so, I would suggest abstracting this logic (and cleanup function) to a common method, so that we don't duplicate this code.

I see it is already duplicated also for the post-processors when applicable, so I would understand if you prefer to continue with this for now, we can always reify this function in a later PR as well.

[jonathanmccormack]

I'm assuming this code is quite similar, if not equivalent, to the code from step_pull.go, is that right?

Yes, it is effectively copied and pasted (with minor conforming cleanup to grab the config from state and refactor some error messages).

If so, I would suggest abstracting this logic (and cleanup function) to a common method, so that we don't duplicate this code.

I see it is already duplicated also for the post-processors when applicable, so I would understand if you prefer to continue with this for now, we can always reify this function in a later PR as well.

I am all in favor of abstracting this logic to keep the code DRY, but was trying to keep my code changes to a minimum so as to make review and approval easier / faster, as the lack of support for login before a bootstrapped build is currently preventing us from using Packer with our configuration. I also didn't want to inadvertently break something, since I am new to this code!

If this otherwise looks OK and you are comfortable approving, I would suggest we keep the duplicated code for the time being. In the meantime I can begin working on a new PR to abstract the the logic, but am guessing that'll take me a bit longer.

[lbajolet-hashicorp]

Oh yeah no pressure on this PR specifically, the current code looks good to me, just wanted to point-out that we could mutualise that logic, but as I mentioned and as you point out as well, this can be done later.

I can probably take care of this once your PRs have been integrated, that way we can proceed with releasing a new version of the plugin next week as well so those changes are usable then.

[lbajolet-hashicorp]

Hey @jonathanmccormack,

FYI, I've just pushed an update to your PR, to address a lint issue on config.go (trailing whitespaces).

Provided tests go green now, I'll merge this PR today.