Request to expand miner filter hooks

[ribasushi]

A request from Murmuration Labs is to expand the set of hook slots for external programs. Currently lotus provides Filter which runs before storage-deal acceptance, and determines whether to accept the deals bytes based on wallet/peerid/payload-cid/other criteria. Request is to expand these hooks as follows:

• ~StorageNegotiationFilter : same as current Filter: receives the JSON of the deal on STDIN and indicates with exit0/1 whether the payment/data for the deal should be accepted~ implemented as Filter
• StorageContentFilter: when specified, upon receipt of the entire DAG from the client, but before inserting it into a WaitDeals sector, an external program receives the DAG determinisitcally on STDIN as a .car stream, and indicates with exit0/1 whether to proceed
• ~RetrievalNegotiationFilter: same as StorageNegotiationFilter but for retrieval deals ( allows blocking of known-unwelcome wallets/peerids, or commP/payloadCIDs that became classified as problamtic material post-sealing )~ implemened as RetrievalFilter
• RetrievalContentFilter: same as StorageContentFilter, the dag is fed to on STDIN prior to graphsyncing the first byte to the client.

It is likely that the 4 hooks will invoke portions of the same suite, which will coordinate caching and known-block-list updates out of band.

[ribasushi]

~Closing ticket for now, the ask was misunderstood, sorry for the noise!~ No, the task is apparently still needed.

[willscott]

for RetrievalContentFilter - we should try to understand if there's a way to implement such a filter deterministically rather than in the critical retrieval path