Resolve symlinked executable path when detecting install root

[Ninja3047]

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Motivation and Context

This allows the container binary to be symlinked to alternative locations for packaging purposes, but still be able to resolve plugins properly. As a workaround, packagers can set CONTAINER_INSTALL_ROOT to the actual install location but this seems more elegant.

Testing

• Tested locally
• Added/updated tests
• Added/updated docs

[jglogan]

@Ninja3047 Can you provide more details in an enhancement issue about the packaging use case you'd like to support?

We just removed some code that relates to this in #1451.

The extension and packaging documentation is still a work in progress but basically, we allow you to symlink to your unpacked package from a unix-like install root (such as /usr/local or /opt/homebrew), but you need to copy your plugin hierarchy from your package root to ${INSTALL_ROOT}/libexec/container/plugin. With this structure there

Third-party plugins should install into ${INSTALL_ROOT}/libexec/container-plugin/${plugin_id}.

If we resolve symlinks for the install root path, then for Homebrew cask installs, the plugins are resolved under Caskroom whose paths change with each release, and this can cause confusion in TCC for local network privacy policy.

We only need to resolve symlinks for the executable path in launchd plists. Here, if we're not pointing to the right place and we're doing bundle packaging, Gatekeeper will keep the executable from launching.