SAMZA-2653: Write pathing jar of run-class.sh into its own directory

[cameronlee314]

Issue: Currently, the pathing.jar file used to specify the classpath for run-class.sh is written directly into the top-level working directory of the app. When using container images, there may be some predefined permissions set on the working directory. This may cause permission issues with being able to write the pathing.jar file.

Changes: Create a separate directory for writing classpath-related files (manifest.txt, pathing.jar) and write the pathing.jar to that separate directory. Update the classpath arguments to use the new location of the pathing.jar.

Tests:

1. ./bin/integration-tests.sh /tmp/samza-tests yarn-integration-tests --nopassword
2. Ran a job using ProcessJobFactory and checked that the job started up.

API changes, usage/upgrade instructions: N/A

Some more context about a specific use case: When I tried to run a container image of the current code in the Kubernetes environment, I ran into a file permissions issue for writing manifest.txt and pathing.jar. This was because the run-class.sh was being run by a non-root user, but the container image did not give write access for the main working directory for non-root users. It makes sense that the main working directory from the container image shouldn't be writable by non-root users, because it could potentially contain binaries/scripts installed in the container image which are needed to execute a Samza job. I couldn't mount a volume in order to give writable permissions to the directory, because that would wipe out the content that was installed to that directory in the container image. It could have worked to run run-class.sh as root, but that isn't ideal from a security perspective. By using a separate new directory, it is easier to apply broader permissions to just this new directory by mounting a volume, and it allows the directories from the container image to continue to have more restricted access.

[Sanil15]

Thanks for the clean up!

[bringhurst]

Note that this PR has a bug. $base_dir ends up being a path symlinked to an application-level __package path.

See #1716 for followup.