Expose the is_likely_native_token_transfer flag for runtime tx method filtering

[csillag]

We have this flag on runtime transactions:

nexus/api/spec/v1.yaml

Lines 3033 to 3042 in c711d6a

	is_likely_native_token_transfer:
	type: boolean
	description: |
	Whether this transaction likely represents a native token transfer.
	This is based on a heuristic, and can change at any time without warning and possibly without updating the documentation.
	The current heuristic sets this to `true` for:
	- Transactions with method "accounts.Transfer". Those are always native token transfers.
	- Transactions with method "evm.Call" that have no `data` field in their `body`. Those tend to be transfers, but the runtimes provides no reliable visibility into whether a transfer happened.
	Note: Other transactions with method "evm.Call", and possibly "evm.Create", may also be (or include) native token transfers. The heuristic will be `false` for those.
	example: true

When this flag is set to true, then on the UI, we indicate the type to be transfer, even if the underlying method is something else. (Most likely, evm.Call.)

However, if we then filter the tx list for transfers (i.e. method=accounts.Transfer ), then these TXs are not returned, since they are technically evm.Call.

This is counter-intuitive, and from end user's POV, inconsistent.

To get consistent results, we also need to consider the flag, so it should be exposed as an input arg for filtering.
If we had that, then:

• To get transfers, we could search for is_native_token_transfer=true
• To get anything else, we would query like : method=evm.Call&is_native_token_transfer=false (to exclude transfers)

If we do this, we could get search results that are consistent with how we display the data according to the flag.

[csillag]

We also need to consider that at one point we will probably want to be able to search for multiple methods at once. (see #877).

Now, if searching for a non-transfer method type looks like this: method=evm.Call&is_native_token_transfer=false, then I find it hard to imagine how to express a search for X, Y and Z non-transfer methods OR a transfer.

The logically correct way would be to say that "(method should be X or Y) OR the is_likely_whatever_transfer flag should be true), but we can't express "OR" in the search params.

One possible way around this would be to go with an alternative implementation for the current issue; one that would fully hide this flag trickery behind the API. We could do that either my re-defining what method=account.Transfer means (by looking at the flag instead), or by introducing another arg, something like smart_method, which would behave similarly to the existing normal method arg, but searching for transfers would look at the flag, and searching for other things would exclude the flag. (Basically the same thing we have described above for the frontend side.)

The advantage of this second approach would be that when making this multi-value, the "OR" thing would fully happen on the server side, where it's possible to describe this in SQL.