Add auth struct to use with New

[UlisseMini]

WIP This is a proof of concept and not done yet! We need discussion about the API and whether to create a new function / method or to just add it to New.

I think we should deprecate New and add a new function (or method on the Auth struct) to get a session.

[iopred]

I like the idea of this being a PasswordAuth struct, and then having 2 fields. Then have a TokenAuth struct with just one field.

No reason to overload the two methods of authentication again, it was confusing as arguments, I don't want it to be confusing with struct members.

[UlisseMini]

I just thought it should have all three, since in the docs for New it says

With an email, password and auth token - Discord will verify the auth
token, if it is invalid it will sign in with the provided
credentials. This is the Discord recommended way to sign in.

So i thought it would be bad to remove the option of using both.

[Stitch07]

IMO getting rid of email/password login would be a good thing, now that Discord doesn't support it.

[CarsonHoffman]

I personally think that this is over-engineering a solution to support a feature that nobody really uses. Email+password login has been officially unsupported for three years now, and other major libraries have dropped support for it long ago (see discord.py: 2017, discord.js: 2018). I have yet to run into a single person seriously attempting to use it in the time that I've been around this library. I think it would be much simpler to just support a string token, which can be used for bots, bearer tokens, and, yes, self-bots, as although they are against TOS they still hold the same major authentication scheme, and hard-coding a Bot token scheme would break the use of bearer tokens, and people wanting to self-bot are just going to edit the library anyways.

[bwmarrin]

Personally, if we're to break the current API on everyone - I'm more in favor of dropping the Email/Pass entirely and just accepting a single token string that we pass along to Discord. It's a closer match to the goal of just being a wrapper around Discord's API and it's simple and easy to use.

The only reason this hasn't been done is because of not wanting to break the API on everyone for such a minor thing. Now with modules and versions and such, I do feel better about making breaking changes to help clean up this library.

[UlisseMini]

I agree with @bwmarrin little point to support email/pass auth, it adds a lot more complexity for little gain.

I'm closing, we can continue this in #649