fix: resolve issue where kaniko would fail if user attempted to create /workspace directory

[aaron-prindle]

Fixes #1508

Context:
#1508 (comment)

Currently a /workspace folder is created when kaniko is run as it is the WORKDIR for the kaniko image. This /workspace folder is deprecated though currently, this directory was renamed /kaniko and it is unclear if the WORKDIR should be set at all for users IIUC. This change removes a WORKDIR from being set which fixes issues where kaniko could not create a /workspace directory as it already existed from it being set as the image's WORKDIR

[JeromeJu]

Thanks for the fix @aaron-prindle . From the integration tests it seems that we might want to add /workspace for https://github.com/GoogleContainerTools/kaniko/blob/main/integration/dockerfiles/Dockerfile_relative_copy after the change IIUC.

[aaron-prindle]

@JeromeJu thanks for the info here! I am hesitant to make this change currently as this test outlines a potential issue where changing the Kaniko image to no longer set the WORKDIR to /workspace might break some users/Dockerfiles that rely on the current functionality.

Additionally this test Dockerfile_relative_copy is essentially testing that WORKDIR is auto-prefixed for relatvie path COPY and would not make sense to change to /workspace (as the test would no longer test relative_copy. Still debating the best thing to do here, it might make sense to simply remove this as it no longer makes sense or have a special kaniko image with a WORKDIR set to test this functionality even if the default image doesn't set it

[aaron-prindle]

Going to close this for now until I have more definitive information on the potential user breakage vs the fix upside (Dockerfiles created /workspace work)