Proposal: Operations should assertState

This is proposal for a new pattern to help developers.

Some adaptors rely on stuff being in state - for example, database-facing adaptors often have some kind of client.

A common bug is for a job to return { data } from an operation - which seems harmless but will accidentally break the job code when an adaptor tries to do state.client.doSomething.

I rebelled against this pattern a little while ago and proposed using a closure rather than state to track clients. I may have forgotten about that stuff. It's still a pattern to consider.

Anyway - for operations that DO rely on state, we should provide a common util function called assertState(state, ...keys)

This function throws if any of the keys are not found on the state object. We can throw a message like Error: 'client' not found on state object. Did you remember to return state from the previous job?

Start by reviewing adaptor operations that rely on state, especially database-facing operations and the pattern of returning state between jobs. Done means a shared assertState(state, ...keys) utility is defined with the proposed missing-key error behavior and supports checking each requested key.