Convert 'ensure' to use a state machine

Note that this is related to #726. I defined mounts as having three states: absent, present, and mounted. Puppet will never mount a resource without first adding it to the fstab, but humans can do so, which confuses Puppet to no end.

Any state machine apparently needs to be able to deal with this situation, either by considering 'mounted' and 'present' related states somehow, or by testing all intermediate states and applying appropriately.

Replying to luke:

Note that this is related to #726. I defined mounts as having three states: absent, present, and mounted. Puppet will never mount a resource without first adding it to the fstab, but humans can do so, which confuses Puppet to no end. Any state machine apparently needs to be able to deal with this situation, either by considering 'mounted' and 'present' related states somehow, or by testing all intermediate states and applying appropriately.

To do this "by the book" you'd have to introduce states for every possible system configuration, correctly detect the current state and then proceed accordingly.

For easier modelling it would be easier in this case to have a separate model for the fstab and the mount itself and then acting on a combined state machine which uses [fstab_state, mount_state] tuples as states. The combined set of transitions is

for each fstab_transition (old_fstab_state, new_fstab_state):
   create_combined_transition ( [old_fstab_state, mount_state], [new_fstab_state, mount_state] )

for each mount_transition (old_mount_state, new_mount_state):
   create_combined_transition ( [fstab_state, old_mount_state], [fstab_state, new_mount_state] )

Some of theses tuples can then be labelled:

( absent, unmounted ) => :absent
( present, unmounted ) => :present
( present, mounted ) => :mounted

Unlabelled states cannot be reached with puppet, only "repaired". If no (known, complete) state is recognized, puppet can abort with an error.

This still seems like we're modeling three distinct states, they are just determined by two status values, rather than just one.

We need a fourth final state, though, for the "absent, mounted" tuple.

Reducing the priority, since it's clearly not as high as plenty others.