preserve .so symlinks for docker container builds

[furrysalamander]

Previous PR #17091 broke the Dockerfiles because everything was previously linking against the unversioned so files. With the versioning added, links are now against the major version symlink for the so files, and copying only the unversion so files is no longer adequate.

This should fix: #17190, #17176, #17193

This PR preserves those symlinks and includes them in the container.

I have not included a fix for the s390x dockerfile in this PR for two reasons:

• the s390x Dockerfile is structured differently than the rest of the Dockerfiles and I want to ensure that the changes are fully tested and validated if we're going to modify it. If I can get some guidance on validating that build I'm more than happy to help.
• I do not want to keep the CI broken for everyone that's not using the s390x Dockerfile while we're fixing that.

For that reason I think it's favorable to open a separate PR for strictly the s390x builds.

[andrew-aladev]

I've tested it locally - it works perfect. Thank you.

@slaren, can you please review this PR? Thank you.

[slaren]

@taronaeo Can you take a look at the s390x Dockerfile?

[slaren]

This is not great because it is creating multiple copies of the same shared libraries. At least the backends aren't duplicated, so it is not a huge problem, but we should switch to using cmake --install.

[furrysalamander]

@slaren The -P flag should preserve symlinks so they're not actually duplicated. That's one of the main reasons I didn't modify the s390x dockerfile because I'd need to alter the structure in order to get the symlinks functional.

[slaren]

That's odd, that's not what I see on my machine.

[furrysalamander]

Are you performing the builds on WSL in a windows directory? I know that that can screw with symlinks. I'm doing my builds in Ubuntu.

[slaren]

It's WSL but it's not on a windows directory.

[taronaeo]

Will look into the s390x docker this weekend :)