Consider adding an "error checking" mode to opt-in to expensive checks of expected data attributes

[vijayiyer05]

Updated issue from original question below.

Two cases have emerged to date for possible error checking:

• Rebuilding spike_times from raw data (API provides raw data, so the preprocessed spike times could be verified)
• Confirming the various fluorescence timebases are equivalent as expected (each fluorescence trace has its own value in API)

Idea of creating a mode would be to keep avoiding doing calculations for expected redundant values generally, but to keep the code/capability allowing checks of the other API/file pathway for equality.

The build_spike_times() method is currently commented out and appears to be a no-op when re-inserted. Not sure what its initial intent was -- does it have an effect for some use cases?

[DylanMuir]

In the Allen API this is a factory method, that re-builds the spike time analysis from the raw data. Since the pre-computed spike times are already present, it was left unimplemented.

[vijayiyer05]

Thanks @DylanMuir for the context. It seems like this could be considered in the context of an "error checking" mode. Updating issue to capture this broader context.