Also send actual expiration timestamp with ethflow orders

[felixjff]

Problem

validTo value for orders in which EthFlow is the owner is constant at 4294967295.

Impact

The value can be used by solvers to avoid orders that will expire within less than the expected auction time. Accurate validTo is useful to ensure batching works out well.

To reproduce

See sample:

https://api.cow.fi/mainnet/api/v1/orders/0x959d1c9867bb036e2f4fe8c536155d8bf097d4a276eb73bb3f655542f185ee6d40a50cf069e992aa4536211b23f286ef88752187ffffffff

Expected behaviour

It seems the actual expiry is available (as see on the sample). We would expect userValidTo to be provided instead of the constant validTo provided at the moment.

"ethflowData": {
"userValidTo": 1728552401,
"refundTxHash": null,
"isRefunded": false
}

services version/commit hash and environment

State the version of services where you've encountered the bug or, if built off a specific commit, the relevant commit hash.

Version / commit hash: 2.279.0
Environment: production

[MartinquaXD]

I'm actually not super convinced this implementation detail should bleed into this interface. Conceptually this is an EIP-1271 order like any other and it's the solver's responsibility to figure out how to handle it. While it's true that the protocol currently has some additional data for this specific kind of orders I think it was a mistake to make it a first class citizen and overall the goal would be to remove special handling of these orders altogether.

As a workaround I would suggest to call the /orders endpoint you linked in the PR and cache the relevant data for incoming ethflow orders.
Alternatively if you have some simulation logic where you can override the timestamp of a block you could simulate the isValidSignature() call with a timestamp in the future that you would like to have the order valid for at least to consider it.