[systemd-devel] workaround for systemd-networkd-wait-online boot fail/delay on systems with bridge for v234? (fix @ systemd/issues/2154 requires v>242)

[PGNet Dev]

 I've switched from distro networking stack (wicked) to systemd-network; generally, what a relief!

The distro (opensuse leap 15.1) has 'old' systemd -- v234

As packaged,

  'systemd-network.service' has "Also=systemd-networkd-wait-online.service".

&

  'systemd-networkd-wait-online.service' has "WantedBy=network-online.target"

A number of my services depend on 'network-online.target'.

All this^ is to say -- if 'network-online.target' is used, 'systemd-networkd-wait-online.service' gets launched.

My box ALSO has a bridge defined.

Which causes me to hit

	"systemd-networkd-wait-online fails with bridged interfaces"
	 https://github.com/systemd/systemd/issues/2154

on boot,

	[  151.868637] systemd-networkd-wait-online[1394]: Event loop failed: Connection timed out
	[  151.884034] systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
	[  151.885593] systemd[1]: Failed to start Wait for Network to be Configured.
	[  151.885714] systemd[1]: systemd-networkd-wait-online.service: Unit entered failed state.
	[  151.885741] systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.

which causes significant delay

	systemd-analyze critical-chain

		multi-user.target @2min 50.841s
        └─...
		  └─network-online.target @2min 19.876s
		    └─network.target @19.712s
		      └─systemd-networkd.service @19.268s +409ms
		        └─network-pre.target @19.249s
		          └─...

The solution @bug is -- upgrade to systemd v242.

On this distro, upstream refuses to upgrade systemd; apparently for them its 'non trivial' and they can't be bothered.  AND, they've a new 'stable' version coming out AnyDayNow(tm), Leap 15.2, for which apparently systemd will REMAIN at broken-like-this^^ v234.

So *my* solution has been to switch distros.  NOT just for this^^ reason, but it was the last straw ...
~ 600 machines have finished migrating to other distros with newer systemd installs that avoid this problem.

BUT -- I'm left with a few boxes that I can't move for awhile.

So ...

	IS there a backport of this^^ fix available for v234 that popped up in the meantime?

	If not, as is likely, is there a "safe" workaround for quieting the fail, and rm'ing the associated boot delay?  Is rm'ing either the "Also=" or "WantedBy=" a reasonable band-aid?

	Or, some other approach?