Debian maintainers changed sshd to notify systemd when it is ready. This notification is only a few lines of code, but it's even _fewer_ lines if you call the sd_notify() convenience function in libsystemd.so
So now you're linking to libsystemd.so. What's also in libsystemd.so? Logging functionality, for programs that need to read systemd logs. That could be in a separate library, but this is systemd, so of course it's not. Everything's in one library. To read compressed systemd logs, libsystemd.so requires a bunch of compression libraries, including liblzma.so.
Anyone linking to libsystemd.so, e.g. to notify at startup, ends up loading liblzma.so, the backdoored version of which abuses glibc ifunc functionality to replace functions in libssl.so in order to take over sshd.
no. anything in the dependency tree could call that lib. systemd is the first. systemd also provides libs to write things the exploit will use. but the important part you missed again is that the exploit is executed on symbols loading. it just choose to do just of the work when checking for a key. but after simply starting the code it's all lost already.
nothing needs to call any code on libzma, just linking against it is enough to run the exploit.
How was the logging functionality of systemd abused by the xz backdoor?