ca-certificates: use relative symlinks from $ETCCERTSDIR

ca-certificates: use relative symlinks from $ETCCERTSDIR

update-ca-certificates symlinks (trusted) certificates
from $CERTSDIR or $LOCALCERTSDIR into $ETCCERTSDIR.
update-ca-certificates can call hook scripts installed
into /etc/ca-certificates/update.d. Those scripts are
passed the pem file in /etc/ssl/certs/ that was added or
removed in this run and those pem files are absolute
symlinks into $CERTSDIR or $LOCALCERTSDIR at the moment.

When running update-ca-certificates during image build
time, they thusly all point into the host's file system,
not into the $SYSROOT. This means:
* the host's file system layout must match the one
  produced by OE, and
* it also means that the host must have installed the same
  (or more) certificates as the target in $CERTSDIR and
  $LOCALCERTSDIR

This is a problem when wanting to execute hook scripts,
because they all need to be taught about $SYSROOT, and
behave differently depending on whether they're called
at image build time, or on the target, as otherwise they
will be trying to actually read the host's certificates
from $CERTSDIR or $LOCALCERTSDIR.

This also is a problem when running anything else during
image build time that depends on the trusted CA
certificates.

Changing the symlink to be relative solves all of these
problems. At the same time, we have to make sure to add
$CERTSDIR to SYSROOT_DIRS, so that the symlinks are still
valid when somebody DEPENDS on ca-certificates-native. As
a side-effect, this also fixes a problem in meta-java,
where some recipes (e.g. openjdk-8-native) try to access
certificates from $CERTSDIR to generate the java trustStore
at build time.

Do so.

Upstream-Status: Inappropriate [OE-specific]
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 09bb7718d74573be9a5db4d0737fb14126f6489c)
Signed-off-by: Andreas Oberritter <obi@opendreambox.org> [edited]