Utilize correct MESSAGE_SIZE

[KyleKotowick]

Prior to commit 1d97873, this value was calculated properly. It was then switched to ctap_types::sizes::REALISTIC_MAX_MESSAGE_SIZE, which was then removed from the ctap_types package, and it was hardcoded at 3072 for an unknown reason in a2104a2.

This PR modifies it back to correctly calculating it as a function of the packet size (giving a max of 7609 with a packet size of 64). The hardcoded 3072 value is insufficient for new post-quantum cryptography algorithms, hence the request to increase it.

[robin-nitrokey]

I think this the same issue as: #3

I’m not sure why the change was made. Maybe to reduce stack usage?

Anyway, I see three possible solutions:

1. re-use the ctaphid-dispatch buffer instead of a separate buffer – would decrease stack usage, but I’m not sure if it is possible
2. bump the buffer size as you suggested – would increase stack usage for all users
3. use const generics for the buffer size – would make the code more complex but allow the choice between increased stack usage and support for larger messages

I’d like to investigate if (1) is possible before deciding between (2) and (3).