idea: require backing module for content all the time

[chu11]

There is a lot of special case code for dealing with the "none" backing module (i.e. is a backing module loaded or not). It may make things simpler if we simply require a backing module all of the time.

Note that we still want to support "no real backing module" for performance (especially for sub-instances), so hypothetically there could be a special "memory only" backing module. or perhaps sqlite run in memory only mode. or dumbly just a backing module called "none" that does absolutely nothing.

[garlick]

Yeah, I think it suffices to say that we have options if we don't want to make content persistent, and also that it's not a situation that's come up IRL recently, so fine to nix it in the name of simplifying code.

It looks like the backing modules all register the content-backing service already so the main thing is eliminating the content.register-backing RPCs and loading the backing module before the cache module. Plus removing the "none" special cases from rc1, not routing the checkpoint stuff through the cache, eliminating code to let the memory cache grow when backing is unavailable, etc..

[chu11]

Yeah, I think it suffices to say that we have options if we don't want to make content persistent, and also that it's not a situation that's come up IRL recently, so fine to nix it in the name of simplifying code.

The performance issue I'm medium concerned with is we will generate unnecessary RPCs. i.e. the content wants to flush to the backing store that does nothing, so it's just a wasted RPC. For sub-instances that don't need a backing store, we are introducing some extra traffic and being busy.

I'm trying to think if there's some "trick" we could do here, but a super clean one isn't coming to mind. One possibly not great idea is to just special case the word "none" as a backing. If "none" is the backing module, content.flush doesn't work and maybe some other RPCs won't. Or perhaps the backing modules will advertise "we can't handle flushes" and the content module can adjust accordingly.

[garlick]

Performance benefits were not compelling as I recall. I'd say just eliminate that option and take the win.