feat: integrate agent store for idempotence & invocation/receipt persistence

[Gozala]

This is a draft that I could not finished on Friday, but I thought I'd share in case @vasco-santos or @alanshaw are looking into related stuff on Monday.

PR introduces AgentStore that is used for writing ucanto AgentMessage's from which receipts and invocations get indexed. This store is then consulted by a service during invocations to provide idempotence or more simply to return receipt without executing a task if we already have one.

Main goal here is to take out custom logic out of w3infra and to remove need for manual receipt / invocation storing in the handlers.

⚠️ It is worth calling out that this is significantly changes how things work. In the past sending same invocation used to re-run the handler, with this change that is no longer the case and you'll get a same receipt back (which is a neat way to lookup receipts actually). However that also means that bunch of our tests were affected. I don't expect it would affect real world cases however, because same invocation send second later will have unique CID (due to how we generate expiry) however it does affect tests because we don't wait a second between calls. That is why nonce's were added in a lot of places, but that is not something I expect users would have to do.

[vasco-santos]

Overall looks good to me!

Not approved essentially because agent store tests should be expanded as reviewed inline

Also worth mentioning, there is a big refactor here on blob/add that would be much easier to be a separate PR instead of intertwined with a lot of other changes. The code seems way better documented for folks without big prior knowledge, so I am happy with these changes still. But made reviewing much more complicated and time consuming

[vasco-santos]

nit: would be great to send this into a DLQ where we could be alerted. Probably an issue for now would be good, as we would also need to do the setup for DLQ monitoring

[Gozala]

We could probably set this up as capability handler and dispatch to it, that way we would be able to throw here which will end up triggering catch handler of the server and get logged instead.

Does that sound like a better option ?

[vasco-santos]

I am not sure why this moved here instead of blob/add. Would you expect that write targets could have different max sizes? Otherwise, I don't understand the change as it results in way more processing for same end result

[Gozala]

I think you are making some good points on this. That said, I also think that I also think there should be no blob/add handler it should be a static workflow like one illustrated here storacha/RFC#25 (comment)

Perhaps what we miss is a prior step that checks that blob size is below the max limit (and that step can even run locally on the invoking agent (like http/put) as opposed to service.

Overall sounds like spec needs to address this by calling out the verification step that needs to take place. In the meantime I suggest we keep this here and we can address this as part of router design which will actually deal with multiple allocation sites. Does this sound reasonable ?

If you feel very strongly about it I can move this back into the blob/add handler, however please note that allocation site would need to have this kind of check anyway as they may have different constraints to work with.

[vasco-santos]

nit: if we need to add further triggers like this in the future, we would need to decouple this into where it is. There is why I would check on it, and I still think it is better to do

[Gozala]

I'm not sure I follow what you are saying here. Are you saying what if we need to resume some other blocked task ? If so I think answer there would to add something like Scheduler.poll(....) which would go and poll each task we need to poll that way logic around individual tasks lives where those task are defined as opposed to been entangled with conclude handler with a branched logic

[vasco-santos]

LGTM after mentioned test in