Add `content` field to `TextDisplay` component

[KiloOscarSix]

Although the Discord documentation omits the content field from the documented response structure, it is present in the actual HTTP response. This field contains meaningful data directly associated with the TextDisplay component, and excluding it results in a loss of relevant information.

Including content would improve completeness and better reflect both actual and expected API behaviour, even if it is currently undocumented.

Adding it as Option<String> would make the most sense, allowing Serenity to handle its removal from the HTTP response gracefully without requiring a breaking change to the struct.

[mkrasnitski]

Can you give an example payload where the content is included in the HTTP response? When I was doing testing for #3454, I was explicitly running into deserialization errors because TextDisplays in modals were being returned with their content field omitted. Granted, I did not test this with message components but modals definitely do not include it.

[KiloOscarSix]

Ah, I did test with a message component, and before the Component refactor, I was heavily using it to manage a Discord game built with ComponentsV2

[KiloOscarSix]

Payload from message component:

RawValue({
    "type":17,
    "spoiler":false,
    "id":1,
    "components":[
        {
            "type":10,
            "id":2,
            "content":"### Blackjack\nYour bet: 100 <:coin:1383692085529415680>\n\n**Your Hand**\n<:5:1383692755917733888> <:9:1383692701987246080> - 14\n\n**Dealer Hand**\n<:7:138369276838727
2704> <:blank:1390357737011155024> - 7"
        },
        {
            "type":1,
            "id":3,
            "components":[
                {
                    "type":2,
                    "style":2,
                    "label":"Hit",
                    "id":4,
                    "emoji":{
                        "name":"🎯"
                    },
                    "custom_id":"blackjack_hit"
                },
                {
                    "type":2,
                    "style":2,
                    "label":"Stand",
                    "id":5,
                    "emoji":{
                        "name":"🛑"
                    },
                    "custom_id":"blackjack_sta
nd"
                },
                {
                    "type":2,
                    "style":2,
                    "label":"Double Down",
                    "id":6,
                    "emoji":{
                        "name":"⏫"
                    },
                    "custom_id":"blackjack_double"
                },
                {
                    "type":2,
                    "style":2,
                    "label":"Split",
                    "id":7,
                    "emoji":{
                        "name":"✂️"
                    },
                    "disabled":true,
                    "custom_id":"blackjack_split"
                },
                {
                    "type":2,
                    "style":4,
                    "label":"Surren
der",
                    "id":8,
                    "emoji":{
                        "name":"🏳️"
                    },
                    "custom_id":"blackjack_surrender"
                }
            ]
        }
    ],
    "accent_color":1752220
})

[mkrasnitski]

Are you using the text display content to manage state? Couldn't you keep track of that state using a Hashmap and the interaction id?

[KiloOscarSix]

Yes, and I can if need be, but it's easier to parse the incoming message, and this way also handles instances where the bot restarts and loses the in-memory cache.
And I could maintain a database, but is more work and network requests than parsing the incoming data