At design time we analyze which objects are retrieved by association from the microflow input parameters, including transitive retrieves (when an intermediate object is stored in a variable). Only "retrieve-by-association" activities are considered, "retrieve-from-database" with xpath constraints on associations are excluded. We record the followed association and in which direction the association is followed. At runtime only the objects which can potentially be retrieved in the microflow are sent along with the request.
In your case this means that the orderlines association is followed from the order input parameter and hence both the order and order lines are sent with the request.
I may be wrong here but since the state is kept in the client Mendix knows exactly what it needs to send. See also this part of the documentation: https://docs.mendix.com/refguide7/monitoring-client-state
FYI There's a new article published today https://www.mendix.com/blog/mendix-7-runtime-changes-stateless-runtime-runtime-api-rest/https://www.mendix.com/blog/mendix-7-runtime-changes-stateless-runtime-runtime-api-rest/ that shows Mendix 7 added information to the runtime logs to monitor what relevant data the webclient sends to the runtime.
Wilfried, your link indeed provides a first clue as to what the answer is:
The client sends data relevant for the request to the runtime. This means the runtime immediately has the relevant data and doesn’t need to get it from a separate state database. This also limits the amount of state that the runtime will need to handle the request. To optimize the size of your request the Mendix platform analyses your application model to determine what data is required by your application.
This is scary stuff. Now I am really curious, how is this analysis performed?