[ZEPPELIN-6459] Align Docker image logging configuration and documentation with Log4j2

[celinayk]

What is this PR for?

Docker-related scripts and docs still referenced Log4j 1.x style log4j.properties files, and the reporter suspected these were obsolete leftovers from a Log4j2 migration. Investigation showed the opposite: Zeppelin's default SLF4J binding is slf4j-reload4j, so log4j.properties is still the primary logging config, while log4j2.properties exists only for Flink's bundled real Log4j2 core — both are required, not obsolete.

The real bug found: DockerInterpreterProcess (the DockerInterpreterLauncher feature) uploads log4j.properties and log4j_yarn_cluster.properties from the host
to the interpreter container, but never log4j2.properties, even though bin/common.sh looks for it via -Dlog4j.configurationFile for every local interpreter process. This PR adds it to the transferred file list, aligns docs/quickstart/docker.md's file list with the code, documents why scripts/docker/zeppelin/bin/Dockerfile needs all 4 log4j* files (so they aren't mistaken for duplicates again), and clarifies in docs/setup/deployment/docker.md that ZEPPELIN_IN_DOCKER applies to the all-in-one image, not the split zeppelin-server/zeppelin-interpreter images.

What type of PR is it?

Bug Fix

Todos

• Add missing log4j2.properties to DockerInterpreterProcess's container file transfer list
• Sync docs/quickstart/docker.md's transferred-file list with the code
• Document why scripts/docker/zeppelin/bin/Dockerfile ships 4 log4j* files
• Clarify ZEPPELIN_IN_DOCKER scope in docs/setup/deployment/docker.md

What is the Jira issue?

ZEPPELIN-6459

How should this be tested?

• No existing unit test covers DockerInterpreterProcess#copyRunFileToContainer
  (it's private and untested), so no automated test was added for the transfer list
  itself; existing DockerInterpreterProcessTest (6 tests) still passes unchanged.
• Manually verified: built the exact tar archive DockerInterpreterProcess produces
  using the same TarUtils/TarFileEntry production classes with the fixed
  copyFiles entries, injected it into a real Alpine container via the same
  upload-tar-then-extract mechanism deployToContainer uses, and confirmed
  log4j.properties, log4j2.properties, and log4j_yarn_cluster.properties all
  land at the expected conf/ path inside the container with content identical
  (byte-for-byte diff) to the host source files.

Screenshots (if appropriate)

N/A (docs/config change, no UI impact)

Questions:

• Does the license files need to update? No
• Is there breaking changes for older versions? No
• Does this needs documentation? Yes — docs/quickstart/docker.md and docs/setup/deployment/docker.md updated as part of this PR