init: split initialization into quasi-idempotent parts

[ahesford]

This is an attempt to overcome issues like #597, where the console blocks waiting for user input and leaves ZFSBootMenu uninitialized for remote logins. Initialization is broken into several functional units, and each is executed and then marked non-executable so that subsequent calls to zfsbootmenu-init will not attempt to run them again. Similarly, early-setup hooks, which are expected to run exactly once, will be marked non-executable after being run the first time for more granularity among these user-configurable components.

Because zfsbootmenu-init is now (more or less) idempotent, /bin/zfsbootmenu can attempt to run it if necessary rather than just spinning forever.

[zdykstra]

Fantastic!

[ahesford]

I tested this by adding a custom script, init.d/25-forever, that just sleeps for an hour. When SSH is enabled in the testbed, I can log in, confirm that hooks before 25-forever are not executable, manaully mark 25-forever non-executable, and run zfsbootmenu to trigger initialization and get a functional menu.

[ahesford]

I'm tempted to make the timed_prompt call in bin/zfsbootmenu much longer than 10 seconds to make attempting to reinitialize more of an opt-in behavior. Maybe something like 3600 seconds and hide the time in the prompt. Thoughts?

[zdykstra]

Extending it out would probably make for more predictable behavior for people connecting over SSH. I see a reasonable way to hack in an infinite timeout into timed_prompt if we want to make that a properly modal dialog.

[ahesford]

OK, I extended your patch to timed_prompt to accept non-positive values for infinite delays, and use that in bin/zfsbootmenu.

[zdykstra]

This all looks great!