Do a bunch more research on IO reboot...
Do a bunch more research on IO reboot...

- Came up with a good way to do progress reporting on noticably timeconsuming operations, which removes the last objection to exporting purely synchronous interfaces... so now we're doing so
- Putting in the groundwork on a Cheney-style options pattern while we're there, just so we track where those sort of fields ought to go
- Tossed in some typedefs on stringy stuff, just for fun
- Accepting the fate that filesystems we produce are going to be stateful fun things.  Which in some ways isn't all bad; putting an Archive method on an Arena instead of having slurpers as their own wholy separate concept with strangely inverted args, and then just using only the appropriate methods in practice... might be interesting, and there's known bonus points for getting input and output filesystems to look the same (look ma, it's all mounts).

But then get the creeping realiziation that Everything is Still Wrong:

- We need state *recovery* mechanisms, which means almost all of this stuff has to be designed around serializable tokens fed to a driver
- And that caching materializer example we wrote was way, way too clued in to tar input systems.  The thing should work with other systems that use mounts, and that means relocation is bonkers, and that blew a cachebust through basically everything about the whole "yielding you a path, deal with it" thing.... so looks like we ARE going to go with a `func(Cacher, Placer) func(Materializer) Materializer` adapter system after all.

Whee.  Being mindful of all the different semantics we someday need to deal with at once is tricky.  I think this is nearing the right thing, though, after we reforge for the last two concerns again.

Signed-off-by: Eric Myhre <2346ad27d7568ba9896f1b7da6b5991251debdf2@exultant.us>

kkroening/repeatr,subuser-security/repeatr,subuser-security/repeatr,kkroening/repeatr,polydawn/repeatr,polydawn/repeatr