feat(member): implement new voice states endpoints

[Snipy7374]

Summary

• Closes implement new voice state endpoints #1216

I did not implement Get Current User Voice State % GET /guilds/{guild.id#DOCS_RESOURCES_GUILD/guild-object}/voice-states/@me because you can get the bot's voice state by doing Guild.me.fetch_voice_state using the common endpoint, let me know if i should implement the other too. Also in Member.fetch_voice_state i'm currently propagating the NotFound error, maybe we could catch it and return None?

Checklist

• If code changes were made, then they have been tested
  • I have updated the documentation to reflect the changes
  • I have formatted the code properly by running pdm lint
  • I have type-checked the code by running pdm pyright
• This PR fixes an issue
• This PR adds something new (e.g. new method or parameters)
• This PR is a breaking change (e.g. methods or parameters removed/renamed)
• This PR is not a code change (e.g. documentation, README, ...)

[shiftinv]

Looks good so far, thanks c:

Updating the cache is definitely a cool idea, though it conflicts with the part you mentioned -

Also in Member.fetch_voice_state i'm currently propagating the NotFound error, maybe we could catch it and return None?

Propagating the NotFound error is the right move, but it does mean voice states added to the cache this way would never get removed again (assuming no voice state intent, since the fetch method is pointless if enabled).

[shiftinv]

I also thought implementing /voice-states/@me would be unnecessary considering /voice-states/{bot.user.id} would be identical, but there actually appears to be one difference - if the bot gets moved to a channel it normally wouldn't have connect perms for, the former endpoint still works, while the latter doesn't.
Special-casing the bot's user ID and using the @me endpoint in fetch_voice_state should be a pretty straightforward fix for this.

[Snipy7374]

Special-casing the bot's user ID and using the @me endpoint in fetch_voice_state should be a pretty straightforward fix for this.

At this point I think we should keep this separated. The best thing is to implement a method on the Client class.

[shiftinv]

At this point I think we should keep this separated. The best thing is to implement a method on the Client class.

On Guild, sure; I don't think it makes sense to have this on Client, though. Being able to fetch a member's voice state without needing to have a Member object in the first place would be a nice bonus.

[Snipy7374]

At this point I think we should keep this separated. The best thing is to implement a method on the Client class.

On Guild, sure; I don't think it makes sense to have this on Client, though. Being able to fetch a member's voice state without needing to have a Member object in the first place would be a nice bonus.

What do we do with the method implemented on the Member class, it looks useless now

[Snipy7374]

At this point I think we should keep this separated. The best thing is to implement a method on the Client class.

On Guild, sure; I don't think it makes sense to have this on Client, though. Being able to fetch a member's voice state without needing to have a Member object in the first place would be a nice bonus.

What do we do with the method implemented on the Member class, it looks useless now

I removed it