feat: endpoint for imapd to authenticate against

[rjsparks]

No description provided.

[rjsparks]

Feel free to suggest a different direction for this.

[codecov]

Codecov Report

Merging #5295 (aebd8dc) into main (61504b1) will increase coverage by 0.14%.
The diff coverage is 93.75%.

@@            Coverage Diff             @@
##             main    #5295      +/-   ##
==========================================
+ Coverage   88.61%   88.76%   +0.14%     
==========================================
  Files         294      287       -7     
  Lines       40061    39701     -360     
==========================================
- Hits        35499    35239     -260     
+ Misses       4562     4462     -100     

Impacted Files	Coverage Δ
ietf/api/urls.py	100.00% <ø> (ø)
ietf/api/views.py	89.79% <92.00%> (+0.25%)	⬆️
ietf/api/ietf_utils.py	100.00% <100.00%> (ø)

... and 16 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[jennifer-richards]

I think we need to fail if User.objects.filter(username__iexact=username).count() > 1 (equivalently, if User.objects.get(username__iexact=username) raises User.MultipleObjectsReturned). Otherwise, if two User records are somehow created with a username collision under iexact, whichever User comes up as first() can log in using either username. Assuming imapd is simply passing the username over as it receives it, it would then allow that password holder to access either account.

This is different from the cases we've dealt with before. If we want to treat it the same way, we would need to report back to imapd not only "success" but the actual username we used in deciding it was a success.