Add ability to pre-declare a stream

[tacaswell]

In discussions with PSI (SLS2) at NSLS-II today it became clear that we need the ability to pre-declare what the streams will be before we create the first event. This will have at least three and a half major benefits

1. it makes the first measurement less special as we can ensure that the describe / read_configuration / describe_configuration happen when we think they wil
2. they will enable the bundler to live in a different process and still correctly accumulate all of the notifications it will need
3. it is now possible to get the descriptor is a custom plan without subscribing to the output stream
4. the RunBundler class is now pluggable by class level monkey patching or thin sub-classing (could be convinced to make it init time configurable...)

In local testing I added a "strict mode" flag to demand that streams are pre-declared and many tests still passed.

[tacaswell]

Open questions:

• do we want this?
• how to manage "strict mode" configuration (probably want 3 modes: YOLO, warn, strict)
• how to thread the stream name through count and the scan_nd family of plans because they take an arbitrary user function than can use a different stream name that 'primary' ?
• how configurable do we want to make the RunBundler class on the RE?

[danielballan]

I think we do want it.

I think we should start with "YOLO" mode only and get some experience with this before we add either "warn" or "strict".

I think that we can defer doing anything helpful or clever with per_step. If anything but the default per_step is used, count and scan_nd can drop the declaration. Users who want both a declaration and a custom per_step have to write a custom plan. As we get experience with this we can consider adding another parameter to deal with this.

I think class attribute is a fine place to start.

[coretl]

The describe cache from read() was previously used here:

Suggested change

	await self._cache_describe(obj)
	if obj not in self._describe_cache:
	await self._cache_describe(obj)

Similar for the read_configuration() and describe_configuration(). Is this refresh of the cache on monitor purposeful?

[tacaswell]

Fixed this and centralized most of this into one place.

Could not fully inline the helpers because collect also uses some of them. Will leave that refactor for the future.

[coretl]

Also, what does "YOLO" mean?

[tacaswell]

YOLO: You Only Live Once

[tacaswell]

It looks like changes to ophyd broke some of the tests?

[coretl]

I'm guessing bluesky/ophyd#1036 might have something to do with it? @callumforrester do you recognise the error?

[cjtitus]

I'm interested in getting this merged. I can try to look at why tests were failing, but as the logs have disappeared it would be helpful to re-run the tests first.

I don't think I can tell GH to re-run the tests, but someone has the power to do that, right?

[danielballan]

Power-cycled to re-run CI

[cjtitus]

Well it looks like turning it off and then back on has "fixed" the previously failing tests. Were the previously open questions ever answered satisfactorily?

Open questions:

* do we want this?

* how to manage "strict mode" configuration (probably want 3 modes: YOLO, warn, strict)

* how to thread the stream name through `count` and the `scan_nd` family of plans because they take an arbitrary user function than can use a different stream name that 'primary' ?

* how configurable do we want to make the RunBundler class on the RE?

I can at least answer the first question and say yes, I want this.
The rest of these were addressed by @danielballan

In order to manage count and scan_nd I think the existing code needs to be changed to avoid pre-declaring a stream if a non-default per_shot is passed in. There is already a check for if per_shot is None to assign the default. This could be when the stream pre-declaration is toggled.

[cjtitus]

Another important question is if strict checking option should be left in RunBundler, but False by default, or if it should be removed entirely for now. If it's False, there's really no way to ever turn it on, unless an option for strict checking were to be added to the RunEngine that could be passed to RunBundler instantiation during open_run

Maybe this is a plausible enough future addition that the code for strict checking ought to be left in?

[tacaswell]

Thank you @cjtitus for pushing on this!

One change I would like to make is to change the strict_pre_declare to an enum rather than a bool (with values "strict", "warn", and "permissive" and change the parameter to "stream_pre_declare_policy" or something like that), but it is not a disaster if it goes in as a bool (and we can promote later it is just annoying to do so).

[tacaswell]

@coretl I think this is ready to go modulo:

• do we want a boolean or a tri-state of the strictness
• public API to make the RE strict