Adds FlowCallbackUtils contract

[joshuahannan]

• Adds a contract that contains utils for callbacks on flow
• Starts out with just CallbackManager, a resource to schedule and cancel callbacks from
• Potentially can have other utils added in the future

It is important to remember that since handlers still need to be created for the actual logic of the callback, this does not allow us to completely standardize the callback transactions because you still need to have code in your transactions to deal with your specific callback handler

I'm still looking for feedback on these changes, so please take a look and let me know what you think. I especially need feedback about usability. I think this improves usability, but I don't always have the best instincts about that.

[bluesign]

In general I really liked the util, but I am also a bit hesitant on this; I think my main issue is I am not clear in my head, who is the actor ?

is it the user ? wallet as agent of user ? or is it the app ?

till now I was always thinking app as the actor, but this utility also makes a good case for user / wallet to be the actor.

[joshuahannan]

@bluesign I think the goal is to design it so that it can work well with any actor. I think this construct definitely makes it easier for individual users or wallets to manage callbacks, but the jury is still out on if this is a good construct for apps to manage callbacks. I think it could be good for that, but I'm not totally sure.

[devbugging]

I can see the utility of this, but don't like the need to change the scheduler contract. This could easily be just a util contract composed on top without changing the contract.
This makes us more flexible in implementing this (instead of last minute change, that wasn't discussed much), and also waiting to see more real world use to implement the contract.
I'm oposed to changing the scheduler contract to fit into util contract.

[mfbz]

This is a great addition. It gives both devs and apps a simple, standardized way to list and manage all callbacks for an account, basically a Flow-native “Task Manager” without third-party indexing.

On the schedule function: making it public is useful since it allows usage with or without the manager that can fit most complicated use cases as mentioned by @sisyphusSmiling. The downside is that callbacks scheduled directly won’t show up in the manager, so extra code would be needed to surface them. If we’re fine with only "standard" callbacks being discoverable, I’m in favor of making it public, otherwise I’d keep it restricted.

Either way, adding the manager feels essential to set a standard for callbacks retrieval for an account.

[joshuahannan]

Looks like the consensus is that the schedule function should be access(all), so I'll change it back to that. Does anyone have any feedback on the manager part specifically, now that it is just optional to use it?

[joshuahannan]

Closing this in favor of #530