What is exactly meant when software-engineers talk about "behaviour" in contrast to "state" (Definition of "state")?
There are multiple layers to the answer.
On the technical level, state is simply the instance variables of an object, and behavior are the methods. Both of these can be extended to other granularity units, like a group of objects or the whole system. Should be clear from the context.
On the semantic ("meaning") level, specifically for object-orientation, both have additional constraints. Not all methods constitute "real" behavior. Getter/setters methods are not behavior for example, because they don't really mean anything in the problem domain. Behavior needs to connect directly with the requirements in some form to be a real behavior.
There may be additional layers of meaning. For example in the context of Domain-Driven Design, I would expect methods to have an even more stricter connection with the vocabulary of the requirements (i.e. the Ubiquitous Language).
It's worth pointing out, that many projects settle for just the technical level, and even in the context of Domain-Driven Design many are completely ok with meaningless methods such as setters/getters in objects and still talk about "behavior" (or "responsibility") in some form. Which may confuse the issue somewhat.
Behaviour is decisions being made.
State is decisions being remembered.
When OOP people talk about behaviour what they mean is the gooey sticky part of the code base that has to be changed every time a business rule changes. Rather than state what this is usually contrasted with is dry structural cerimonial code that exists mostly because the system or language requires it of us. A lot of work just goes into keeping these separate.
But if we're going to contrast behaviour with state then I'll flat out admit that the difference is just in our heads. Code and data are the same thing. This is something hackers love to exploit. We accept their data and they figure out how to make us treat it like code.
Behaviour is a construct of our minds about what we want the system to do. Behaviour code is code that focuses on that ideal. It's an illusion but it's what we're imagining when we say it. State is the result of what's already been done. It might be used in the decisions to come. We don't think of it as making the decisions. But again, this distinction is all in our heads. Really, code or data, behavior or state, it's all really just numbers.
But that doesn't mean it's a meaningless distinction. The computer might not care about the difference but the humans do. The differences comes from intent. We separate these ideas so we can make the behavior we expect clear.
I think this is an interesting question, that not many people are aware of even asking.
From a general software perspective, I like to see it as follows:
Behaviour drives state, and state can potentially drive behaviour
It is a two-way relationship, because certain actions can trigger certain flows to be executed, while within some flows, certain actions can be triggered.
So, if we execute an action, like:
Click on a submit button to submit a form, different things might happen if the form is complete or incomplete, warnings might be triggered, emails might be sent, DB records might be created or updated, etc.
Each of these actions on the other hand, might trigger new actions to be taken, etc. So, it's clearly a two-way relationship.
From a more OO perspective, say, that an object, Dog, can perform an action, like, eatTreat().
When the dog eats, a TreatSupplier class might need to be updated internally, to reduce the biscuit amount by one.
If the biscuit count reaches 0, we can say that the biscuit supplier was put in a certain state due to an action taken by the dog.
These kind of relationship between state and behaviour is a big part of how OO-structured systems work.