Jib should maintain hard-links and symlinks

[briandealwis]

The hardlinking supported by the Spotify docker-client can result in large image-size savings for situations using lots of hard-links (jvanzyl/dockerfile-maven#2). Jib should track hard-links. Jib should also preserve symlinks (perhaps only if they reference within the layer?).

[jvanzyl]

Great savings in the time to produce the image as well, give far less material is transferred.

[briandealwis]

The relevant starting point is com.google.cloud.tools.jib.api.buildplan.FileEntriesLayer#addEntryRecursive().

[dfelliott]

It is trivial to add support for symlinks to com.google.cloud.tools.jib.image.ReproducibleLayerBuilder#build.

Just use the standard Java Files.isSymbolicLink API on the sourceFile and if it is a symlink create a TarArchiveEntry for a symlink using the result of Files.readSymbolicLink. If not a symlink, the existing code for creating a TarArchiveEntry is correct.

There's a little bit more to it if the source filesystem isn't UNIX or if the target of the link is not a relative path. Still, it would be nice if ordinary symlinks with relative targets "just worked" and it's a pretty trivial change here to make that happen. One might argue if the path is absolute then presumably it's already intended for the container so nothing special has to be done with it.

There is one major catch though: the current behavior is to follow symlinks, so changing will break any builds that rely on the follow behavior.

[meltsufin]

@dfelliott Thanks for the idea. However, this FR is not currently prioritized.

[chanseokoh]

We gave some thought on this in the past, and we think we want a new dedicated configuration and API in jib-core.

Note this idea has been around for some time (#1576) actually.