Change token field type from CharField to TextField in AbstractRefres…

[hb-joel]

Fixes #1557

Description of the Change

This pull request changes the AbstractRefreshToken model in django-oauth-toolkit by updating the token field from a CharField to a TextField. This modification allows for greater storage capacity and prevents the django.db.utils.DataError caused by exceeding the character limit (255) for the CharField.

By switching to TextField, we ensure that the refresh token can accommodate larger values, which may be needed as token sizes or encoding formats evolve.

Checklist

• PR only contains one change
• Documentation updated to reflect changes made

---

This PR should resolve the token size issue. Let me know if you need any further adjustments to the description or additional information!

[n2ygk]

TextFields are not searchable for certain database backends. This feels like something recently discussed in another PR.

[n2ygk]

See #1447

[komarov]

As another user of DOT, I would like to kindly challenge the approach of changing these base models: both AbstractRefreshToken (in this PR) and AbstractAccessToken (in #1447, which in hindsight I would even view as a mistake).

My perception may be incorrect, but I see the swappable models as a better solution to these exceptional cases of requiring larger storage for token payloads. This keeps the project core code more suitable for a broader audience, but still accommodates more specific use cases.

Bringing in support for every [marginal] use case into the project core leads to unfortunate situations when a token checksum becomes larger than the original payload, the storage of the token payload moves out of the db page (engine-dependent), and it is impossible to opt-out from this overhead because the base code now requires a checksum to exist. And my guess would be that most users of the project don't benefit from this choice.

To support these custom models we would need to have a flexible mechanism (e.g. a method override) for a token lookup, allowing the core code to delegate the storage choice and the lookup implementation to the custom swappable model.

I don't know if it's too late to come up with a plan for AbstractAccessToken, but I think it would be good to consider a different way forward for AbstractRefreshToken and not proceed with this PR as it is now.