Set the overwrite flag on unzip

[dankreek]

Add overwrite flag to unzip command

🗣 Description

Overwrite existing foundry application files when starting a container that has already been created.

💭 Motivation and Context

I noticed while using the container in a docker-compose stack that if I do a stop then an up the container freezes while asking the user to overwrite the Foundry application files.

🧪 Testing

I tested this change on a Digitalocean droplet that I'm running foundry on.

I did docker-compose up on the stack, then a docker-compose stop.
I then did another docker-compose up and everything came back up as expected.

✅ Checklist

• This PR has an informative and human-readable title.
• Changes are limited to a single goal - eschew scope creep!
• All future TODOs are captured in issues, which are referenced in code comments.
• All relevant type-of-change labels have been added.
• I have read the CONTRIBUTING document.
• These code changes follow project standards.
• All relevant repo and/or project documentation has been updated to reflect
  the changes in this PR.
• Tests have been added to cover the changes in this PR.
• All new and existing tests pass.

[felddy]

Thank you for taking the time to create this PR.

It would be helpful if you could open a bug report issue that describes the behavior you are seeing: https://github.com/felddy/foundryvtt-docker/issues/new?assignees=&labels=&template=bug.md

Then we can rework this PR to address it. Without some diagnostic log information I can't be sure that we are talking/thinking about the same scenario.

Off the top of my head, I think you the issue you are seeing would be contained in the container entrypoint and not the Dockerfile.

Thank you again, I hope we can nail this down.

[felddy]

Same comment. Doesn't address issue in description.

[felddy]

This modification doesn't address the issue in the description. These changes modify the way "pre-baked" Docker images are built, not how the runtime system installs FoundryVTT when it is not found.

[felddy]

@dankreek I opened issue #148 to document the behavior you are reporting in this PR. I was unable to reproduce it. I'd like to track down the root cause. While this PR should fix it, the container shouldn't be able to get into that state to begin with. This leads me to believe that there is another logic issue somewhere else.

Would you please paste some log output showing how you were able to get the container to stop for a user prompt in #148.

Thanks.