Contract log fetching / querying is unnecessarily inefficient in multiple respects

[fubuloubu]

When iterating over event logs, it is very slow to collect them together, because it tries to iterate over the entire blockchain's history, when the contract only deployed at some block within that history:

ape/src/ape/api/providers.py

Lines 917 to 934 in 4f53967

	def get_contract_logs(self, log_filter: LogFilter) -> Iterator[ContractLog]:
	height = self.chain_manager.blocks.height
	start_block = log_filter.start_block
	stop_block_arg = log_filter.stop_block if log_filter.stop_block is not None else height
	stop_block = min(stop_block_arg, height)
	block_ranges = self.block_ranges(start_block, stop_block, self.block_page_size)
	def fetch_log_page(block_range):
	start, stop = block_range
	page_filter = log_filter.copy(update=dict(start_block=start, stop_block=stop))
	# eth-tester expects a different format, let web3 handle the conversions for it
	raw = "EthereumTester" not in self.client_version
	logs = self._get_logs(page_filter.dict(), raw)
	return self.network.ecosystem.decode_logs(logs, *log_filter.events)
	with ThreadPoolExecutor(self.concurrency) as pool:
	for page in pool.map(fetch_log_page, block_ranges):
	yield from page

1. Event log start block should be bound to whenever the contract was first deployed, to the point it last existed (SELFDESTRUCT). If there is a change in contract code within using a CREATE2 proxy, those might make changes to end block as well
2. How batching works can be extremely inefficient. Some blocks have no events, and some have a lot.
3. Web3py provides a direct API for filtering events, some research should be done to determine if that might improve this section of code
4. Further work should continue to be done on the query layer, which might vastly speed up the process of obtaining logs via data pipeline plugins

[fubuloubu]

Some elements were resolved in #1548, but further research is required if the above mentioned elements are still valid (and if there are more)