fix: don't return session_not_found on logout, make it idempotent

[hf]

If you call POST /logout with a JWT whose session cannot be found in the database, it means that one of these cases occurred:

• The API call was retried, such as by the user clicking the button multiple times too fast.
• The user signed out from device A and then proceeds to sign out from device B within the JWT expiry period.
• The session was deleted outside of the logout flow, such as by manually running a DELETE FROM sessions query.

If this was done, the logout request failed with a session_not_found error code. With this change, the logout request succeeds.

[kangmingtay]

i'm ok with the idea of making the logout action idempotent but i'm not a fan of how we handle it in the middleware function conditionally

i'd prefer if we have a new middleware function which maybe calls requireAuthentication internally but ignores the SessionNotFound error

[cstockton]

I believe we should keep the behavior as is, first it seems like the most correct behavior. Second and most importantly it's the behavior we have now, it could potentially break application flows that depend on being able to make a positive assertion on if a logout session previously existed or not.

If we do decide to do this, I agree with @kangmingtay that the change should be in Logout. We probably want to add some basic tests too, as implemented this change would just panic with an NPE here for local & others scope instead of returning a better error:
https://github.com/supabase/auth/blob/master/internal/api/logout.go#L52