bliss: Fix build with DEBUG_LEVEL < 2

sqlite: Fix build with DEBUG_LEVEL < 2

pkcs7: Fix build with DEBUG_LEVEL < 2

constraints: Fix build with DEBUG_LEVEL < 1

revocation: Fix build with DEBUG_LEVEL < 1

x509: Fix build with DEBUG_LEVEL < 2 for structures that ignore unknown critical extensions

plugin-loader: Fix build with DEBUG_LEVEL < 3

auth-cfg: Fix build with DEBUG_LEVEL < 1

certificate: Fix build with DEBUG_LEVEL < 1

credential-factory: Fix build with DEBUG_LEVEL < 1

crypto-tester: Fix build with DEBUG_LEVEL < 1

asn1: Fix build with DEBUG_LEVEL < 2

debug: Add macro to mark variables that are only used in DBG statements

Some variables that are only assigned to be used in DBG statements
will otherwise trigger a "set but not used" warning/error if DEBUG_LEVEL
is too low.

doxygen: Enable JS search engine

doxygen: Fix syntax for some output parameters

ikev1: Migrate CHILD_SAs when IKE_SA is reset during reauthentication

When we reset the initiator SPI, we have to migrate the adopted children
again so the correct IKE_SA can later be checked out.

Closes strongswan/strongswan#1663

vici: Improve log messages for terminate/rekey() in case of combined filters

As long as any `child*` selector is received, only CHILD_SAs will be
terminated or rekeyed.  Any passed `ike*` selectors will only be used to
filter the IKE_SAs when looking for matching CHILD_SAs.  However, the
previous log messages seemed to indicate that IKE_SAs will also be
terminated/rekeyed.

References strongswan/strongswan#1655

vici: Create default TCP socket on Windows in Python bindings

This uses the same value as VICI_DEFAULT_URI.

References strongswan/strongswan#1655

charon-systemd: Add a log message when the daemon is starting

While there is a status message sent to systemd (can be seen e.g. in
systemctl status), the version etc. is currently not logged to the
journal, syslog or any log files.

leak-detective: Add `on_exit(3)` to whitelist

Seems to allocate some TLS value in newer glibc versions.

controller: Add parameter for maximum log level to initiate/terminate_*()

Previously, the logger installed by the controller always announced
LEVEL_PRIVATE(4), which produced completely useless logging calls with
the common clients (vici/stroke) whose default log level is LEVEL_CTRL(1).
This can produce quite some overhead if there are e.g. a lot of concurrent
initiate() calls.

controller: Ignore log messages unrelated to IKE_SA affected by a command

Until we know which IKE_SA is affected by an initiate() or terminate_*()
command, unrelated log messages that don't have any IKE context (i.e.
the passed `ike_sa` is NULL) would previously get logged.

watcher: Prevent busy wait if callback is active and other FDs have events

Exiting the loop previously could cause watcher to busy wait (i.e.
rebuild the array and call poll() repeatedly) until the active callback
was done.

Assume watcher observes two FDs 15 and 22, which are in the list in that
order.  FD 15 is signaled and its callback gets triggered.  The array of
FDs is rebuilt and does not include 15 anymore.  Now FD 22 is ready for
reading.  However, when enumerating all registered FDs, the loop previously
was exited when reaching FD 15 and seeing that it's active.  FD 22 was
never checked and the array was immediately rebuilt and poll() called.
If the callback for 15 took longer, this was repeated over and over.

This basically reverts d16d5a245f0b ("watcher: Avoid queueing multiple
watcher callbacks at the same time"), whose goal is quite unclear to me.
If it really wanted to allow only a single callback for all FDs, it didn't
achieve that as any FD before an active one would get notified and if
multiple FDs are ready concurrently, they'd all get triggered too.
Skipping entries with active callback makes sense as it avoids a lookup
in the FD array and subsequent revents checks.  But why would we need to
rebuild the array if we see such an entry?  Once the callback is done,
the watcher is notified and the array rebuilt anyway (also if any other
FD was ready and jobs get queued).

watcher: Move debug log messages out of mutex

The list of FDs is recreated quite often (e.g. due to the kernel-netlink
event sockets) and if a logger depends on watcher_t in some way this
might cause conflicts if the mutex is held.

watcher: Make sure to re-activate the correct entry after a callback

Since the same FD may be added multiple times (e.g. with separate
callbacks for WATCHER_READ and WATCHER_WRITE), the previous check
might not have found the correct entry.  As the entry can't be removed
while in a callback, the pointer comparison is fine.

watcher: Log when watched FDs are added, removed or updated

watcher: Only log number of managed FDs

Adding the internal notify FD might be confusing.

watcher: Avoid logging on level 1 while holding the mutex

This could be problematic in case loggers in some way rely on watcher_t
themselves.  This particular log message should rarely occur if at all,
but still avoid holding the mutex.

vici: Don't lock connection in write mode when enabling on_write() callback

This should prevent a deadlock that could previously be caused when a
control-log event was raised.  The deadlock looked something like this:

 * Thread A holds the read lock on bus_t and raises the control-log event.
   This requires acquiring the connection entry in write mode to queue the
   outgoing message.  If it is already held by another thread, this blocks
   on a condvar.

 * Thread B is registering the on_write() callback on the same connection's
   stream due to a previous log message.  Before this change, the code
   acquired the entry in write mode as well, thus, blocking thread A.  To
   remove/add the stream, the mutex in watcher_t needs to be acquired.

 * Thread C is in watcher_t's watch() and holds the mutex while logging on
   level 2 or 3.  The latter requires the read lock on bus_t, which should
   usually be acquirable even if thread A holds it.  Unless writers are
   concurrently waiting on the lock and the implementation is blocking
   new readers to prevent writer starvation.

 * Thread D is removing a logger from the bus (e.g. after an initiate()
   call) and is waiting to acquire the write lock on bus_t and is thereby
   blocking thread C.

With this change, thread B should not block thread A anymore.  So thread D
and thread C should eventually be able to proceed as well.

Thread A could be held up a bit if there is a thread already sending
messages for the same connection, but that should only cause a delay, no
deadlock, as on_write() and do_write() don't log (or lock) anything while
keeping the entry locked in write mode.

Closes strongswan/strongswan#566

sonarcloud: Ignore "User-defined types should not be passed as variadic arguments"

This triggers an error for functions that take chunk_t as variadic
arguments (cat, debug, builders, ASN.1 wrap).

Since we are not using C++, this should be fine as we are only passing
POD types anyway.

Version bump to 5.9.11dr3

cert_cache: Replace cached stale OCSP responses in-place

Version bump to 5.9.11dr2

pki: Filter whitespace in base64 encoded EST responses

As clarified in RFC 8951, section 3.1 [1].

[1] https://www.rfc-editor.org/rfc/rfc8951#name-white-space-processing

Co-authored-by: Tobias Brunner <tobias@strongswan.org>
Closes strongswan/strongswan#1616

pki: Add support for EST server label

As specified in EST RFC 7030, Section 3.1 [1].

[1] https://www.rfc-editor.org/rfc/rfc7030.html#section-3.1

Merge branch 'pkcs7-signatures'

Adds support for CMS-style signatures in PKCS#7 containers, which allows
verifying RSA-PSS and ECDSA signatures.

Ed25519 signatures should be supported when verifying, however, they
currently can't be created.  Ed448 signatures are currently not supported.
That's because RFC 8419 has very strict requirements in regards to the
hash algorithms used for signed attributes.  With Ed25519 only SHA-512 is
allowed (pki currently has an issue with Ed25519 in combination with
SHA-512 due to its associated HASH_IDENTITY) and with Ed448 only SHAKE256
with 512-bit output, which has to be encoded in the algorithmIdentifier
parameters (something we currently don't support at all).

Closes strongswan/strongswan#1615

pki: Allow specifying signature scheme for PKCS#7 signatures

Also changed the error handling a bit so it is more like in the other
pki commands.

pki: Unify parsing of RSA padding scheme and fix disabling PSS

If PSS padding is enabled by default, not all commands allowed disabling
it explicitly.

openssl: Add support for CMS-style signatures in PKCS#7 (RSA-PSS, ECDSA)

pkcs7: Add support for CMS-style signatures (RSA-PSS, ECDSA)

For the legacy schemes with rsaEncryption nothing changes, but if an
actual signature scheme is encoded we use that to find the key and
verify the signature.

The descriptions for the PKCS#7 structure are adapted for CMS.

asn1: Allow suppressing log messages when parsing algorithm identifiers

botan: Pass n and e separately for RSA public keys

Some encoders, like those provided by the dnskey and sshkey plugins,
require these separately when encoding keys.

Also fixes the type for the ASN.1 encoding (which is a subjectPublicKeyInfo
structure) depending on the key type.  This worked fine for PEM encoding
as the pem plugin doesn't care what the actual type of the key is (which
is encoded in the SPKI structure), but other plugins do (e.g. the sshkey
plugin).

ipseckey: Add support for ECDSA and EdDSA public keys

Use wolfSSL 5.6.0 for tests

The `--enable-heapmath` configure option has been deprecated.  As
already described in eae30af029b1 ("Use wolfSSL 5.4.0 for tests"), the
alternative is to configure `--with-max-rsa-bits=8192` instead in order
to test the modp6144 and modp8192 DH groups.

Version bump to 5.9.11dr1

revocation: Suppress some log messages for cached OCSP responses

We don't have any information on the issuer of cached OCSP responses, in
particular if the OCSP response is issued by a dedicated OCSP signer,
whose certificate might not be contained in the response or even signed
by the same CA but could just be locally installed.  So the only way to
determine if a response applies to the current certificate and its CA
is searching for the response's issuer certificate and verifying that.

However, when using multiple CAs that provide revocation checking via
OCSP, in particular with multi-level CAs (e.g. like the
ikev2-multi-ca/ocsp-signers test scenario), we might have unrelated OCSP
responses in the cache when verifying a particular certificate.  In this
case we don't need any confusing

  ocsp response verification failed, no signer certificate '...' found

error messages because the response was for a different CA.

Similarly, if lots of clients of the same CA connect there could be lots
of OCSP responses in the cache that, while being applicable to the current
CA, don't have any information on the certificate we are currently
checking.  In this case all the

  ocsp response correctly signed by "..."
  ocsp response contains no status on our certificate

messages don't provide any value.

In the mentioned test scenario, we suppress the

  ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=Research OCSP Signing Authority, CN=ocsp.research.strongswan.org' found

message from the cached OCSP response for carol's end-entity certificate
when verifying the "Research" intermediate CA certificate that issued
carol's certificate.

Then the

  ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=Research OCSP Signing Authority, CN=ocsp.research.strongswan.org' found
  ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=OCSP Signing Authority, CN=ocsp.strongswan.org' found

messages from the cached OCSP responses for carol's end-entity and
intermediate CA certificates when verifying dave's end-entity certificate.

And finally the

  ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=Research OCSP Signing Authority, CN=ocsp.research.strongswan.org' found
    ocsp response correctly signed by "C=CH, O=strongSwan Project, OU=OCSP Signing Authority, CN=ocsp.strongswan.org"
    ocsp response contains no status on our certificate
  ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=Sales OCSP Signing Authority, CN=ocsp.sales.strongswan.org' found

messages from the cached OCSP responses for carol's end-entity
certificate, the applicable but unrelated response for carol's "Research"
intermediate CA certificate and the response for dave's end-entity
certificate when verifying dave's "Sales" intermediate CA.

testing: Fix installation of swid-generator with newer versions of setuptools

With version 60.0.0 setuptools changed to a local installation of
distutils.  This seems to break the installation of swid-generator (causing
an `importlib.metadata.PackageNotFoundError: swid-generator` error).

Note that while Debian ships setuptools 52.0.0, `python-daemon` recently
added a dependency on `setuptools>=62.4.0`, which installs that version
that's then later used to install swid-generator.

The main difference seems to be that the local version installs the
package in `/usr/lib/python3.9/site-packages`, while the stdlib version
does so in `/usr/local/lib/python3.9/dist-packages` (similarly for the
`swid_generator` script and the `distro` dependency).

Not sure if there is a better/proper way to fix this.  Might just be an
issue with Debian bullseye and mixing system packages with those installed
via pip3.

Merge branch 'crl-sign'

Enforces that the certificate that signed a CRL either encodes the
cRLSign keyUsage (even if it is a CA certificate) or is a CA certificate
without a keyUsage extension (which should rarely be the case nowadays).

This is in compliance with RFC 5280, section 6.3.3. (f):

  If a key usage extension is present in the CRL issuer's certificate,
  verify that the cRLSign bit is set.

strongSwan encodes a keyUsage extension with cRLSign bit set in all CA
certificates it generates since 1ec8f22de222 ("set Certificate Sign and
CRL Sign flags in keyUsage extension if CA is true"), which was 13 years
ago.  Before that the extension was not encoded so those CA certificates
would also still be accepted as CRL issuer (if they are still valid, but
considering the SHA-1 deprecation that happened since then, they were
most likely replaced anyway).

References strongswan/strongswan#1548

openssl: Only allow certificates with cRLSign keyUsage to sign CRLs

x509: Only allow certificates with cRLSign keyUsage to sign CRLs

openssl: Set X509_CRL_SIGN for CA certificates without keyUsage extension

x509: Set X509_CRL_SIGN for CA certificates without keyUsage extension

appveyor: Build eap-radius plugin on Windows

libradius: Link to winsock32 on Windows

eap-radius: Don't include socket.h explicitly

We rely on the includes via utils.h so this compiles on Windows.

windows: Fix compat define for sendto(2)

kernel-wfp: Install bypass policies also on FWPM_SUBLAYER_IPSEC_TUNNEL sublayer

This is apparently necessary to bypass tunnel mode SAs/policies.

References strongswan/strongswan#1552

windows: Fix invalid pointer dereference when terminating service thread

When running as a service, the libraries are initialized/deinitialized
not by the main thread but by a separate thread that runs the registered
main service procedure.  When the service is stopped, the libraries are
deinitialized by that thread and the thread lock and hashtable are
destroyed.  But afterwards the DllMain callback is also triggered for
that thread so we have to prevent it from accessing these objects again.

References strongswan/strongswan#1567

controller: Immediately return after re-initiating an existing IKE_SA childless

If no CHILD_SA is initiated, we wait for a state change to IKE_ESTABLISHED
but that will never happen for already established IKE_SAs.

References strongswan/strongswan#1553

vici: Fix fallback to remote ID if no mediation peer ID is configured

Also adds error reporting via VICI for issues with mediation settings.

Fixes: 229cdf6bc8f2 ("vici: Order auth rounds by optional `round` parameter instead of by position in the request")
References strongswan/strongswan#1569

dhcp: Don't use get_source_addr() to determine source address

That method is subject to interface filtering, which isn't ideal for
DHCP traffic that probably uses an internal interface on which the IKE
daemon might be disabled.  In that case `giaddr` is set to an incorrect
public IP, which in turn might prevent the plugin from receiving the
DHCP server's unicast response, in particular if the DHCP socket
is bound to the internal interface.

This new approach connects the client socket and thereby determines the
source address to reach the DHCP server.

Closes strongswan/strongswan#1573

pki: Fix enum for SCEP CA capabilities

As indicated by the comparisons and the parsing in scep_parse_caps()
this should be a bitmask.

Fixes: 7c7a5a0260ca ("pki: Enroll an X.509 certificate with a SCEP server")
Closes strongswan/strongswan#1607

eap-tls: Fix server implementation with TLS 1.2 and earlier

With 5401a74d3608 ("eap-tls: Add support for TLS 1.3") a TLS application
was added to implement TLS 1.3's protected success indication.  For
earlier TLS versions, its build() method simply returned SUCCESS as
there was nothing to send.  However, that had the unintended side-effect
of also not sending the final TLS handshake messages (ChangeCipherSpec
and Finished).

The reason is that the TLS stack first checks for remaining handshake
messages but then also asks the registered application for data to
piggyback to that response (before the commit there was no application,
so that step was skipped).  The problem is that the status returned by
the application is directly forwarded through the TLS stack.  So not
returning INVALID_STATE caused the session to get concluded immediately
instead of resulting in ALREADY_DONE that would trigger sending the
final EAP message instead of an EAP-Success.

Fixes: 5401a74d3608 ("eap-tls: Add support for TLS 1.3")

tls: Only return EAP MSK if TLS handshake is complete

The MSK is generated when the keys are derived.  For TLS 1.3 that's also
when the handshake is complete.  However, for TLS 1.2 it happens when
generating or processing the ClientKeyExchange message, which, on the
client, happens before the final Finished handshake message has been
received from the server.  This caused the EAP-TLS client to accept an
EAP-Success message instead of the server's final TLS handshake
messages, unintentionally allowing servers to cut the exchange short by
two EAP messages (in the regular exchange the response to the server's
final handshake messages is an empty EAP-Response, which is then
followed by the server's EAP-Success).

While this is not correct, it does not seem to pose a security issue.
If DH is used as key exchange, the server signs the ServerKeyExchange
message and the client is sure to communicate with a trusted server
before it derives the MSK.  If RSA encryption is used as key exchange,
the client sends the premaster secret, on which the MSK is based,
encrypted with the server's public key (as extracted from the trusted
certificate).  An attacker won't be able to decrypt this and, therefore,
can't derive the same MSK to generate a valid AUTH payload and the IKE
authentication will fail.

github: Add LSan workaround for tests on Ubuntu 20.04 again

This was removed with 0fea6a7f8e7e ("github: Adapt to switch to Ubuntu
22.04 for ubuntu-latest") as it didn't seem necessary anymore.  But
recently there have been such random crashes again with the 20.04 image.

github: Use OpenSSL 3.1.0 for tests

vici: Generalize timeout support in Python bindings

Since 3dd5dc50119d ("Merge branch 'vici-python-timeout'"), any timeout
set directly on the socket is reset by `vici.Transport.receive()` unless
called by `vici.Session.listen()`. This prevents configuring a default
timeout directly on the socket.

However, setting a timeout directly on the socket also had drawbacks
since it can cause `vici.Transport.receive()` to raise a timeout error
while a subset of the data have been received, with no way to recover.

This commit merges both approaches by considering the timeout configured
on the socket by default (when no timeout is explicitly set) and
keeping the switch to blocking receive once the first byte has been
received. When the full expected data have been received, the timeout
configured on the socket is restored.

Co-authored-by: Tobias Brunner <tobias@strongswan.org>
Signed-off-by: Jean-Tiare Le Bigot <jt@yadutaf.fr>
Closes strongswan/strongswan#1562

github: Don't build on Ubuntu 18.04 anymore

The Ubuntu 18.04 image is deprecated and builds will start to fail
temporarily during four 24 hour periods from now until the final
deprecation on April 1st.  So better remove these runs now.

appveyor: Fix LDFLAGS for Windows build

With newer OpenSSL builds, the DLL files contain parts of the version
number and the architecture in their name, e.g. for OpenSSL 1.1.1 the
DLL for libcrypto is called libcrypto-1_1-x64.dll.  So referencing that
directly could be kinda tricky.  And by using `-lcrypto` we therefore
didn't link those DLLs but the OpenSSL version installed by msys2.
Since the latter ships OpenSSL 3 since January and the VS 2019 image
was updated recently, our builds broke as we used the headers from
the 1.1.1 installation but then tried to link OpenSSL 3.

Luckily, in the lib/ directory of the OpenSSL installation, there is a
libcrypto.lib file, which is an import library (containing the symbols
and a reference to the DLL).  We can use that to link the right library
via `-lcrypto`.

With the old OpenSSL 1.0.2 build on the VS 2015 image, there is also
such a .lib file but it seems the linker is too old or otherwise incapable
of finding the DLL.  But since the DLL is just called libeay32.dll there,
we use that directly and don't reference the lib/ dir.

Also removed a superfluous AC_MSG_RESULT() if libeay32 isn't found.

appveyor: Install gperf manually on newer versions of msys2

Version bump to 5.9.10

NEWS: Add info about CVE-2023-26463

eap-peap: Initiate Phase 2 immediately for TLS 1.3

Before TLS 1.3, the server sent the last handshake message and had the
option to piggyback the EAP-Identity request directly onto the packet
with the TLS Finished message, or wait for the empty message by the
client that acknowledges the completion of the handshake.  With TLS 1.3,
the client finishes the handshake after the server.  So this option
is irrelevant there and we immediately start with Phase 2.

testing: Negotiate TLS 1.3 for part of the EAP-TLS scenarios

NEWS: Add news for 5.9.10

pki: Add possibility to add/remove flags in requests when issuing certificates

pki: Allow overriding EKU flags from certificate request via command line

The flags encoded in the PKCS#10 structure (or derived from the encoded
profile name) might not be appropriate in some instances. This allows
overriding them without having to issue a new certificate request.

Version bump to 5.9.10rc1

testing: Add a failing client to the ikev2/rw-eap-tls-only scenario

libvici: Fix Doxygen comment for vici_on_close()

Fixes: 9e5533fef940 ("libvici: Add callback invoked if connection is closed by daemon")

swanctl: Fix Windows build of --monitor-sas command

Fixes: 4784c92c557f ("swanctl: Terminate --monitor-sa command if daemon closes connection")

utils: Add counterpart to wait_sigint() to explicitly stop waiting

Merge branch 'nm-xfrmi'

Use XFRM interfaces instead of dummy TUN devices to avoid issues with
name resolution if supported by the kernel.

Closes strongswan/strongswan#1048

charon-nm: Use an XFRM interface if available

This allows NM more freedom in regards to how it wants to use the passed
device.  In particular, if dnsmasq is used with NM as that binds to the
interface to send requests via VPN.

Installing the VIPs on lo avoids weird address removal/addition events
that happen for IPv6 on the physical interface (which would cause the VIP
to get incorrectly detected as non-VIP address and ignored during
deletion).

We could let NM install routes via XFRM interface, however, that causes
problems with e.g. the bypass-lan plugin (the throw routes in table 220
wouldn't have any effect).  We could let it install regular routes in
the main table, but determining the physical interface would be tricky
as the routes installed by NM, also in the main table, would conflict.

So instead we let the kernel-netlink interface install routes via XFRM
interface and to avoid routing the IKE traffic that way, we set a mark
on the IKE socket and exclude traffic with that mark from our routing
table.

kernel-netlink: Add an option to install routes for SAs with XFRM interfaces

Since these might conflict with IKE traffic, this requires special care.
One option is to install bypass policies for the peer, which install
appropriate (throw) routes.  However, that won't work if the traffic to
the gateway itself should be protected, in particular, for host-to-host
tunnels.  So an alternative is to set a mark for the IKE socket and then
exclude that traffic from table 220 via the kernel-netlink plugin's
fwmark option.

kernel-netlink: Automatically bring up XFRM interfaces after creation

kernel-netlink: Add manager for XFRM interfaces

The manager will allow charon-nm to create XFRM interfaces if supported
by the kernel instead of creating an unused dummy TUN interface.

The xfrmi tool is mostly obsolete nowadays as iproute2 supports creating
XFRM interfaces since 5.1.0 (2019-05).  Older Debians don't ship that and
early versions didn't list the interface IDs.  So there might still be
some uses for this tool.

charon-nm: Tie lifetime of dummy TUN device to connection

NM doesn't terminate charon-nm after disconnecting, so the TUN device
previously stayed around even if no connection was established.  This
might be a bit more what users expect.

eap-tls: Add support for TLS 1.3

As defined in RFC 9190, a "protected success indication" (0x00) is sent
from the server to the client over the TLS connection when using TLS 1.3.

The client responds with an empty EAP message, which is interpreted as
acknowledgement in our stack.

If we ever support session resumption with tunneled methods such as
EAP-TTLS, we'd have to send such an indication there too.

tls-crypto: Fix MSK calculation for TLS 1.3

As noted in 121ac4b9e37e ("tls-crypto: Generate MSK for TLS 1.3"), the
calculation was only preliminary.  It is now fixed according to RFC 9190
and draft-ietf-emu-tls-eap-types (soon to become an RFC, currently in
the RFC editor queue).

Fixes: 121ac4b9e37e ("tls-crypto: Generate MSK for TLS 1.3")

Merge branch 'kernel-netlink-sa-lastused'

Adds support for a change in Linux kernel 6.2 that allows retrieving
the last use time of an SA from the SA itself instead of having to query
the policies.

kernel-netlink: Increase log level for dumped Netlink messages

Some of these contain key material so they should be logged on level 4.

android: Announce support for TFC padding

Has been supported by libipsec for a long time (since 5.1.1).  UDP encap
is already enforced via config, this just makes the flags the same as
in kernel-libipsec.

kernel-netlink: Read last use time from SA if possible

Since 6.2 the Linux kernel updates the last use time per SA.  In
previous releases the attribute was only updated and reported for
specific outbound IPv6 SAs.

Using this reduces the number of kernel queries per CHILD_SA: for DPDs
from two policy queries (IN/FWD) to a single query of the inbound SA,
and for status reports the three policy queries (IN/FWD/OUT) can be
omitted and only the two SAs have to be queried.  For NAT keepalives the
number of queries doesn't change but a policy query (OUT) is replaced by
a query for the outbound SA.

While we could use the existence of the attribute as indicator for its
support, we don't know this until we queried an SA.  By using a version
check we can announce the feature from the start.

child-sa: Query policies only if querying SAs doesn't update the use time

kernel-interface: Add feature to indicate if query_sa() returns last use time

Currently supported by libipsec and PF_KEY on macOS (FreeBSD, like Linux,
reports the time the SA was first used in sadb_lifetime_usetime - it also
triggers rekeyings based on that, which Linux doesn't, it also triggers
them if an SA is never used).

ikev2: Add option to prefer childless IKE_SAs as initiator

swanctl: Terminate --monitor-sa command if daemon closes connection

libvici: Add callback invoked if connection is closed by daemon

github: Explicitly install pkg-config in macOS build

Apparently not installed anymore in the latest build image.  If it's
missing, we see errors like these:

  configure.ac:38: error: possibly undefined macro: AC_DEFINE