phosphor-ipmi-flash: Next Iteration of Control

[Patrick Venture]

I was thinking, since I'm going to extend phosphor-ipmi-flash to
support updating a BIOS -- it might make sense to make it more general
further.  I was thinking about how right now, there are default
services you can implement for each thing, prepare, verify, update,
and currently we don't install them (although I was going to implement
a default prepare service).

I was thinking that possibly adoption would be easier if they were
targets instead of service files directly and then we'd always install
the targets:

- phosphor-ipmi-flash-prepare-update.target (always called when
starting up a process each time a new process is started)
- phosphor-ipmi-flash-verify-bmc.target
- phosphor-ipmi-flash-update-bmc.target

Then a user can just install their services into the targets and not
have to really worry about doing anything more.  I think it's equally
as usable as before, but ... I don't know.  This way, it always
installs the targets.

I was thinking about this further and was thinking about how
everything is compiled into the application, dynamically/configurable,
but compiled in.

If it's going to start supporting BIOS, and then later other firmware,
perhaps the list of Blobs and their associated actions should be
configured via json.  There is a limitation to this though that if
that's the case, then the ActionInterface used for different things
would really just become a SystemdActionInterface and we'd use
services to control everything.  In theory, the json could specify the
ActionInterfaceType from a list and the parameters after that point
would be per type..., but I think that's getting a bit easy-to-break.

Those are just some thoughts I had today.

Regards,
Patrick