Add allowed_mentions to `ClientBuilder`

[Khsmty]

description:

Currently, there is no allowed_mentions in the ClientBuilder, so it is necessary to specify allowed_mentions for each message to be sent. It would be useful if it could be specified like FrameworkOptions in poise.

impression:

let client = Client::builder(token, intents)
    .allowed_mentions(
        CreateAllowedMentions::new()
            .all_users(false)
            .all_roles(false)
            .everyone(false)
            .replied_user(false)
    )
    .await
    .unwrap()

[kangalio]

I don't think this is something serenity should implement, being an unopinionated library. Why do you need this feature in serenity, when it is provided by poise?

[Khsmty]

Sorry, I must have misunderstood about serenity and poise. You are right, there is an allowed_mentions in the poise configuration, so it was not necessary for serenity.

[Khsmty]

@kangalio May I ask one question? Is there any other way to reply Embed in an event handler than using new_message.channel_id.send_message()? If use this method, you need to specify allowed_mentions in CreateMessage individually.

[kangalio]

There is not, unfortunately

[TheKodeToad]

Sorry if this is a necro - but I don't see why this feature is considered opinionated, it's quite important. The only other option when using serenity rather than poise is to specify on every message that you do not want pings. Perhaps defaulting to a set of mentions would be opinionated... but that's not necessary

[kangalio]

but I don't see why this feature is considered opinionated, it's quite important

True, I was sloppy with my wording. When I said opinionated, I really meant something different: serenity tends to map the Discord API rather closely. Global allowed_mentions is a feature Discord does not have in any way, which means serenity would have to emulate it by adding passing down the global allowed mentions into every message send endpoint, which would increase coupling between parts of serenity in a way we usually try to avoid.

All that said, I was a bit shorted-sighted in my initial judgment and you're right that the above is not necessarily a reason to discard the proposal. After all, we also coupled gateway and HTTP in #1772 so users don't have to keep track of their ApplicationId manually even though those two components are separate.