For some reason I am not sure of yet, the multipathd.socket seems to
be inconsistent in being enabled during the tgtbasedmpaths test.

This is technically fine, as long as the service is enabled.

This creates an issue with the check I recently added to monitor the
socket. In my manual testing I always saw the socket enabled, but in
Debian's CI[0] and Ubuntu's CI[1], some architectures are failing.
Interestingly, amd64 in Debian's CI is failing[2], but is passing just
fine for Ubuntu[3].

I say for now, let's _allow_ the socket to be inactive at startup, but
only inactive which is a return code of 3 from systemctl. Thus, the
autopkgtest will accept a return code of either 0 or 3. I have staged
this change[4] in MR!17, please consider it.

Welcome to additional thoughts on this too, apologies on the troubles
adding this one line has caused, but it's highlighting an
inconsistency which is exactly what I wanted to keep a lookout for.

[0] - https://ci.debian.net/packages/m/multipath-tools/
[1] - https://autopkgtest.ubuntu.com/packages/multipath-tools
[2] - https://ci.debian.net/packages/m/multipath-tools/unstable/amd64/
[3] - https://autopkgtest.ubuntu.com/packages/multipath-tools/oracular/amd64
[4] - https://salsa.debian.org/linux-blocks-team/multipath-tools/-/merge_requests/17