A backup cluster for tids <= backup_tid has all data to provide regular read-only ZODB service. Having regular ZODB access to the data can be handy e.g. for externally verifying data for consistency between main and backup clusters. Peeking around without disturbing main cluster might be also useful sometimes.

In this patch:

• master & storage nodes are taught:

  • to instantiate read-only or regular client service handler depending on cluster state: RUNNING -> regular BACKINGUP -> read-only

  • in read-only client handler:

    • to reject write-related operations
    • to provide read operations but adjust semantic as last_tid in the database would be = backup_tid

• new READ_ONLY_ACCESS protocol error code is introduced so that client can raise POSException.ReadOnlyError upon receiving it.

I have not implemented back-channel for invalidations in read-only mode (yet ?). This way once a client connects to cluster in backup state, it won't see new data fetched by backup cluster from upstream after client connected.

The reasons invalidations are not implemented is that for now (imho) there is no off-hand ready infrastructure to get updates from replicating node on transaction-by-transaction basis (it currently only notifies when whole batch is done). For consistency verification (main reason for this patch) we also don't need invalidations to work, as in that task we always connect afresh to backup. So I simply only put relevant TODOs about invalidations for now.

The patch is not very polished but should work.

/cc @jm, @vpelletier, @Tyagov