Should we split out stratis-utils into two separate scripts?

[mulkieran]

At present it contains only three distinct scripts, stratis-predict-usage and two systemd-related setup generators used by dracut subpackage.

We could split it into two.

One would only contain stratis-predict-usage and would be built along with stratisd. One would only contain the systemd generators and would be built along with stratisd-min, and stratis-min.

Advantages:

1. Likely will simplify packaging in future.
2. We had some concern about hard links across filesystems. Currently, our install step hardlinks both systemd generators to stratis-predict-usage. These are potentially cross-filesystem links. If we split in two, we could drop the cross-filesystem links and just link between the systemd generators.

Not-an advantage:
Fedora/RHEL packaging always builds stratis-utils with support for systemd-generators. What that means is that someone who just installs stratisd and not stratisd-dracut will get stratis-utils w/ the systemd generators enabled. That's OK, just confusing to have to pick through the steps and flags in the spec file. It would be a bug if someone who just installed stratisd did not get stratis-predict-usage, but that does not happen.

Considerations:
Both stratis-predict-usage and the systemd generators depend on the engine feature but for very different reasons. stratis-predict-usage requires a bunch of internal information about sizes which are in the engine data structures. The systemd generators make use of systemd bindings which are generated by the stratisd build step in order to log. The logging has proved valuable previously. The systemd generators dependency could be dropped and the logging retained, but then we lose the benefits of code reuse that we get from using the systemd bindings.