Fix .zprofile is owned by root

[joshspicer]

We got a report that the remoteUser's .zprofile was owned by root, which was causing subsequent tools to fail to write to that file (eg: updating PATH). Along the way noticed some interesting changes introduces in #736 that I think might be the cause, or at least appears to be an anti-pattern to me.

This change reverts a previous change. I don't think we should be sourcing a .profile at all in .zprofile (mixing bash and zsh scripts). There's perhaps some extra configuration that we need to port over to .zprofile, which should be reviewed and added in a follow up change.

context/ slack

[markphip]

I do not think it is actually sourcing root, it is echoing that as a line of code into the file, which then sources it at runtime. That is questionable since it is a bash file and may not run.

The issue is that the file is being created by echo so it is owned by root and unlike the earlier code in this script, the owner is not changed after.

Reverting probably makes sense until a proper .zprofile can be written. Having the test should be great for the next time this change is attempted

[joshspicer]

Yea, agreed after some more testing.

Updated to add an empty .zprofile if there isn't one already, and assert that the file is owned by remoteUser. Make sense to you @markphip ?

[markphip]

Yes, I think that is reasonable. sourcing .profile likely needs to be revisited because it seems likely there will be scenarios that does not work but I'd imagine @samruddhikhandale tested that manually and it at least is working in the simple scenarios where the file can be handled by zsh.

The file being owned by root was the main problem introduced here