chore: setup withdrawable event queue

[gusin13]

Fixes - babylonlabs-io/staking-api-service#188

[jrwbabylonlab]

The more I think about it, the more it feels like passing everything down via msg might have been the wrong decision.

Perhaps passing down just a staking transaction hash would be sufficient and letting the API handle the lookup instead. 🤔

I’m trying to approach this from an extensibility perspective—considering whether this approach is flexible enough to support new features in the future.

[gusin13]

hmm good question - if we let api query the db on every event, it would cause load on db no?
we don't have any db cache or something in api so all the queries would go to mongo.

so basically it boils down to
queue bandwidth(storage) vs db query load 🤔

[jrwbabylonlab]

The queue bandwidth is fine since we’re not passing large-sized content. This is more of an extensibility concern.

For instance, if we add new metadata to the database, we can avoid modifying the queue code and instead rely on the API(or other) service to handle its own lookups.

While database load is a valid concern, MongoDB performs some internal caching for recently accessed documents. As long as the data has been accessed recently, the performance should remain reasonable.

In any case, this is neither a concern nor a blocker for this PR, in my opinion. It’s something we can revisit in the future, @kirugan, if there’s a need to redesign this communication pattern.

[jrwbabylonlab]

Approved with some small comments/questions