EmptyNodeCapabilities for chains that don't discriminate nodes

[neysofu]

Provides a default NodeCapabilities implementor called EmptyNodeCapabilities, so that new chains can use that without writing their own, assuming they don't need any custom logic.

Also "fixes" the PartialOrd implementation of Ethereum's NodeCapabilities, which is not buggy per se but breaks the required trait invariants.

Related to #3260.

[leoyvens]

I believe we can remove this type from the trait entirely, the only place I can see that's really requiring it is here https://github.com/graphprotocol/graph-node/blob/bdd2434bd03142c20859615ea7cf899b6361df48/core/src/subgraph/instance_manager.rs#L281 and that could be refactored to take the list of onchain_data_sources as an argument instead of NodeCapabilities.

[neysofu]

Alright, I think I see how indeed we can remove all traces of NodeCapabilities from the Blockchain trait. Some problems arise with BlockStreamBuilder::build_firehose though, where the current flow of logic is TriggerFilter -> NodeCapabilities -> TriggersAdapter via Blockchain::triggers_adapter. This can be transformed into TriggerFilter -> &[Chain::DataSource] -> TriggersAdapter, but getting the data sources out of a TriggerFilter is not immediate and it would require refactoring that trait as well. I'd leave it for a future PR, unless I'm missing something and it's easier than that.

[leoyvens]

Afaict fn build_firehose does not have a good reason to be constructing a triggers adapter. I only see it used here

graph-node/chain/ethereum/src/chain.rs

Lines 627 to 631 in e519812

	// triggers in block never actually calls the ethereum traces api.
	// TODO: Split the trigger parsing from call retrieving.
	let block_with_triggers = adapter
	.triggers_in_block(logger, BlockFinality::NonFinal(ethereum_block), filter)
	.await?;

That TODO isn't hard to fix, this block needs to be extracted to a new fn parse_triggers and that should be used directly instead of going through the triggers adapter

graph-node/chain/ethereum/src/chain.rs

Lines 529 to 536 in e519812

	let mut triggers = Vec::new();
	triggers.append(&mut parse_log_triggers(
	&filter.log,
	&full_block.ethereum_block,
	));
	triggers.append(&mut parse_call_triggers(&filter.call, &full_block)?);
	triggers.append(&mut parse_block_triggers(&filter.block, &full_block));
	Ok(BlockWithTriggers::new(block, triggers))

[neysofu]

I had totally forgot about this. I never pursued the follow-up refactoring, should we merge it as it is (after fixing conflicts)?

[leoyvens]

Isn't this just (&self.archive, &self.traces).cmp((&other.archive, &other.traces)).

[neysofu]

No, Rust tuples define lexicographic ordering, which is not what we use for node capabilities comparisons (e.g. all fields have to be >= in order for a NodeCapabilities to be >, but if we just compare them as tuples, the comparison might stop at archive and discard traces).

[leoyvens]

I see, thanks