Implement support for multiple sockets for systemd activation

[onyxmaster]

Implements support for multiple sockets when using systemd socket activation by taking into account the %LISTEN_FDS%. Attempts to preserve backward feature compatibility, falling back to default number of sockets to be 1.

Addresses #24067

[halter73]

byte. Is it documented anywhere that LISTEN_FDS cannot be larger than 127?

[onyxmaster]

No, this is actually allowed to be in range of [1;INT_MAX-3], but I thought it might be a good idea to limit it to a more reasonable number since I don't really believe that supporting inheritance of INT_MAX-4 sockets is a practical idea because I don't think it would be robust and/or testable.

[onyxmaster]

Still, matching systemd's "native" functionality is not an issue to me, if you believe this is a correct way of handling this.

[onyxmaster]

I also opted out of hard failure when invalid values for %LISTEN_FDS% (like 0 or -84) are presented, not sure if this is a proper course of action, since systemd "native" library is very explicit about invalid values (considers this an error) and missing envvar (treats this as a non-socket-activated case).

[halter73]

Sorry for the slow reply, I think we should change this to an int. If LISTEN_FDS is really large, so be it.

[onyxmaster]

No problems, Stephen, had a lot on my plate recently too. I'll match sd_listen_fds behavior then.

[onyxmaster]

I think I fixed this, also rebased to more recent head.

[onyxmaster]

It occured to me that the basic testing framework based on a docker container appears to be dead now, killed when Travis was removed and it wasn't picked up by the new CI pipeline.
This complicates things because it prevents regression testing. I don't believe I'm acquainted enough with the current build system (Azure pipelines) to fix the test-related issue in a reasonable amount of time.

[halter73]

@onyxmaster You're correct to point out that we no longer have regression testing for the logic in UseSystemd since we stopped running tests on Travis. We do have a test for socket handles in general, but that's not affected by this change.

You don't need to take responsibility for adding regression tests where there currently are none (thought that would certainly be welcome). For now, manual verification should sufficient.

[onyxmaster]

Thanks. I would really like to provide a test, and I think that taking a look at Azure Pipelines would be interesting, but I really don't have time for this right now 😔

[onyxmaster]

It does look like CI failures are unrelated to introduced changes. Would you please take a look?

[halter73]

Thanks @onyxmaster!