Allow session to work with callbackQuery and inlineQuery

[EdJoPaTo]

When using the session on inline queries or on inline buttons sent from inline queries the defaultGetSessionKey was useless and errored: Cannot access session data because the session key was undefined!

With this change both inlineQuery (which has from) and callbackQuery (which has either chat or chat_instance) work out of the box.

[KnorpelSenf]

Please change the documentation on grammy.dev and link the PR here. I'll merge afterwards.

[EdJoPaTo]

When reading the documentation it isn't very specific about the default behaviour of the default session key. It only tells that the session in general is a neat thing to handle data per chat which isn't changed by this PR.

callbackQuery.chat_instance is still the chat (but can be a different key even if the chat is the same) and inlineQuery.from is chat independent in general but this also doesn't change the idea of the session to help with keeping data of chats. If someone wants a different key (for example always ctx.from) it's also described and also isn't changed by this PR.

Am I overlooking something?

[KnorpelSenf]

I changed my mind while considering this PR again. Despite being a small change, it has non-trivial consequences for users when updates are handled concurrently.

For example, when running on webhooks, Telegram delivers updates sequentially per chat. Changing the default session key resolution suddenly lets updates read and write session data concurrently, e.g. once from a chat itself and then at the same time during an inline query. This PR can therefore lead to data loss. Hence, it is a breaking change.

The same is true for users of grammY runner.

I understand that it is inconvenient that sessions do not work with the default configuration for inline queries, but we need to acknowledge that reading and writing data concurrently to the same object is a hard problem and we should be careful with our defaults.

Do you have any other ideas how to accomplish this benefit?

[EdJoPaTo]

For example, when running on webhooks, Telegram delivers updates sequentially per chat.

This sounds like a dangerous assumption as its out of control for this library.

---

Independent from this change people should be aware of race conditions and that atomic changes are always best for handling them. (But most stuff isn't atomic)
https://grammy.dev/advanced/scaling.html#concurrency-is-hard already notes this and suggests using sequentialize.

I guess this would spark a discussion about many major / breaking releases with small impact vs few big breaking releases or separation of logic vs centralized logic.

As we can't add smaller breaking changes well currently I don't see this change being merged. When needed the getSessionKey can be overwritten so its a simple change anyway.

[KnorpelSenf]

This sounds like a dangerous assumption

I don't think it'll change soon. The Bot API server developer confirmed this behaviour, so it seems like we can rely on it.