fix priority access list estimator

[sunce86]

If one of the access list estimators returns global Ok result, but with Err for each individual transaction, then it is meaningful to try with other access list estimators rather then returning the result.

For example, this happens for Web3 access list estimator when node does not support eth_createAccessList method.

I think this change needs to be part of the PriorityAccessListEstimating rather then part of the NodeAccessList, because this type of result (global Ok result, but with Err for each individual transaction) is perfectly valid from the NodeAccessList point of view (we asked the node something and it returned a valid batch response).

[MartinquaXD]

IMO it would be nice for such a case to check that the node actually supports access lists during initialization. If a node doesn't support that API it could then return an Err() immediately instead of making network calls to eventually return Ok(Vec<Err>) every time. This would prevent the problematic NodeAccessList to not add any latency.
Does this change originate from this slack thread?
If so, it seems like the problem this PR solves is not that common and could be solved quickly by fixing our nodes. In that case I wouldn't mind pessimizing latency temporarily to make the implementation as simple as it is right now.

[sunce86]

IMO it would be nice for such a case to check that the node actually supports access lists during initialization. If a node doesn't support that API it could then return an Err() immediately instead of making network calls to eventually return Ok(Vec) every time. This would prevent the problematic NodeAccessList to not add any latency.

Yes, nice suggestion. I would maybe just skip adding the NodeAccessList to the PriorityAccessListEstimating list in case it does not support the method.

Does this change originate from this slack thread?

Yes, nice catch :)

If so, it seems like the problem this PR solves is not that common and could be solved quickly by fixing our nodes. In that case I wouldn't mind pessimizing latency temporarily to make the implementation as simple as it is right now.

That was also my reasoning. This is just a temporary situation and I expect it to not happen anymore after OE is removed from our nodes (other clients should already have a support).