systemd service provider starts/enables in the wrong order

The systemd provider for the service resource type seems to always start a service before enabling it. This behavior does not work for the rsyslog service. Enabling the rsyslog service must happen before starting it because enabling it creates symlinks for syslog.service to rsyslog.service. Those are necessary for the syslog.socket unit to work properly which is again required by rsyslog.service. Thus starting rsyslog.service is not possible, before it has been enabled.

How to reproduce:

1. Prepare environment
$ systemctl stop rsyslog.service
$ systemctl stop syslog.socket
$ systemctl disable rsyslog.service
$ systemctl is-active rsyslog.service
unknown
$ systemctl is-enabled rsyslog.service
disabled

2. Try to activate rsyslog through puppet (will fail)
$ puppet apply --debug --execute 'service

{ "rsyslog.service": ensure => 'running', enable => true, provider => 'systemd' }

'

3. Activate rsyslog manually (how puppet should do it)
$ systemctl enable rsyslog.service
$ systemctl start rsyslog.service

The relevant log messages from step 2. are:

Debug: Executing '/bin/systemctl is-active rsyslog.service'
Debug: Executing '/bin/systemctl is-enabled rsyslog.service'
Debug: Executing '/bin/systemctl start rsyslog.service'
Error: Could not start Service[rsyslog.service]: Execution of '/bin/systemctl start rsyslog.service' returned 1: A dependency job for rsyslog.service failed. See 'journalctl -xn' for details.
Error: /Stage[main]/Main/Service[rsyslog.service]/ensure: change from stopped to running failed: Could not start Service[rsyslog.service]: Execution of '/bin/systemctl start rsyslog.service' returned 1: A dependency job for rsyslog.service failed. See 'journalctl -xn' for details.