Add @no_infer flag for turning off species/variable/parameter inferring

[vyudu]

Probably missed some places where we do this, @TorkelE might appreciate some guidance when you can. Also probably need some more tests to catch edge cases

[isaacsas]

Maybe we want to instead have our own error type UndeclaredSymbolicError that we throw instead of calling error? Then we can more precisely @test_throws UndeclaredSymbolicError to verify this is working in all the different cases?

It might also be helpful if the equation/reaction can be displayed in some way too to actually show a user precisely where the error is occuring.

[vyudu]

It might also be helpful if the equation/reaction can be displayed in some way too to actually show a user precisely where the error is occuring.

Might need write some more pretty-print utilities for ReactantStruct and ReactionStruct if we want to do this, right now the way they show is very long and hard to parse. I'm happy to add these as part of this PR if it wouldn't get too bloated

[isaacsas]

Yeah, adding a show for them sounds useful.

[TorkelE]

The itnended behaviour is that all species/parameters/variables have to be declared using the corresponding options? Wouldn't a better name bet require_declaration?

Also, a small request, can we hold of merging this one a bit? I am trying to sort out the observables PR (think it is working locally, but need to test during the weekend), working in the DSL file is increasingly messy, and this changes some of the relevant code. Ideally I had wanted #985 to be merged before any further changes to the DSL code (since that makes it way easier to modify), but it is getting further and further away. if possible, after this and the osbervablwes fix, could we hold of further DSL changes until that one gets sorted out?

[TorkelE]

(this is definitely useful stuff though, I'll have a look tomorrow morning)

[isaacsas]

I'm fine with holding off on further changes after the observables fix and this one get merged (and with merging observables first), if you will be actively working on the older one afterwards.

[TorkelE]

Yes, that is the plan. Although I just remembered we decided to change how un-declared symbolic variables in equations is handled (always set to variables, instead of for special cases). Since that is breaking I probably should do that one asap as well.
(and ofcourse, if we discover any more bugs, that might have to take residence as well, but hopefully it can all be sorted out quickly)

[TorkelE]

In the main make_reaction_system function we already have variables

parameters_extracted
species_extracted
vars_extracted
add_default_diff

listing all symbolic variables we inferred from the input. I think it would be easier (since we don't have to pass an additional argument into each function and add separate checks to add a but to the main function like

if noinfer && (!isempty(parameters_extracted) || ...)
    error("...")
end

Then we can also make it more granular, checking each separately with a designated error messages saying which symbolic variables must be designated.

This would also solve and old issue that I think @gaurav-arya raised some time (but I maybe it was just mentioned over lunch and never made it to a actual issue, couldn't find it when I looked)

[isaacsas]

@TorkelE I don't feel super strongly about this, but there are a couple advantages to the approach here:

1. It is eager, so as soon as a problem arises a user is informed. For large networks this could be useful to save waiting.
2. It offers the possiblity to provide useful error messages on where the inferred variable is coming from.

I think 2. is the main reason to keep this approach. If we only check after collecting everything we can only report something was improperly inferred, but not where it was inferred from. If we keep the current approach we should try to display for users enough context to easily find the line that is causing a problem.

[vyudu]

@require_declaration does sound like a better name, happy to roll with that

[TorkelE]

@isaacsas (As you say) I don't think (1) is much concern here. I could see how 2 could be an advantage if there is a situation where you have mistakenly used a symbolic name which you do not need to use (x instead of X), checking only in a bunch is useful only in the case when you mean to declare x but forgot about it.

We probably should modify the error messages to give the equations/reaction in question then.

[isaacsas]

This looks good to me. @TorkelE can we merge?

@vyudu please followup now with doc updates and an entry in the HISTORY.md.

[TorkelE]

Technically, rn = is not needed in these cases

[vyudu]

Closes #1045

[isaacsas]

@vyudu please don't forget the followup doc and HISTORY.md updates.