[FEATURE] Have per-conversation data (or at least an identifier) in ConversationHandler

[vmsh0]

What kind of feature are you missing? Where do you notice a shortcoming of PTB?

When first learning about PTB and particularly about ConversationHandler, it felt quite natural to me that there should be a per-conversation data store, or at least some kind of identifier to univocally identify each conversation.

Describe the solution you'd like

I would like to to have a per-conversation data store, available in callbacks called from a ConversationHandler, e.g.

async def some_conversation_callback(update, context) -> int:
    context.conversation_data['some_key'] = update.message.text
    return WHATEVER

This would be cleaned up after a conversation has ended (following all the usual per_* semantics).

Alternatively, a conversation identifier would be a viable alternative:

async def some_conversation_callback(update, context) -> int:
    conv_id = context.conversation_id
    context.bot_data[conv_id] = {}
    context.bot_data[conv_id]['some_key'] = update.message.text
    return WHATEVER

However it must be noted that this alternative has the downside that it requires manual cleanup in all final states (currently END and TIMEOUT), making this bearable but somewhat error-prone.

Describe alternatives you've considered

I have considered subclassing ConversationHandler and monkey-patching it by overriding all the relevant methods to associate a dictionary to each new conversation and destroying it when reaching a final state; and by subclassing CallbackContext to have an additional property to point to this dictionary. I have made a mock-up of this idea which works fine, but this is difficult to support because it relies on manually reviewing the internals of ConversationHandler after each library upgrade.

Duplicating the entire ConversationHandler implementation also achieves a similar result, while having the milder but still relevant downside that I won't get features and bugfixes automatically :)

I have also considered manually managing this per-conversation data storage manually in the handler functions of each conversation. However, as described above, the lack of a reliable way to get a per-conversation identifier makes this also somewhat difficult to support, because it requires at the very least to keep this per-conversation data login manually synchronized to the identity semantics of the chosen per_* parameters. The internal conversation key would be a suitable identifier, as by definition only one conversation at a time can ever exist at once for each conversation key. A UUID or serial number might be more useful for some user applications (albeit not mine!).

Additional context

Somewhat related to #2331

[Bibo-Joshi]

Hi. Thank you for reaching out. Refactoring CH is a long standing item on our to-do list and we are gathering a bunch of ideas related to it in #2770. Conversation related data is in fact already one of them. I've linked your description in that issue.
For the time being, I unfortunately don't see us adding additional features to the existing CH class. One of these days we'll just have to get started on a new implementation...
I'll close this issue in favor of tracking the ideas in #2770, but this certainly does not mean that I reject the idea :)