Retrieve only user external logins when invalidate following removal of backoffice external user login

[AndyButland]

Prerequisites

• I have added steps to test this contribution in the description below

Resolves #19742

Description

The initial implementation of #19273, added to ensure backoffice user sessions relating to removed login providers are invalidated, distinguished between users and members, such that only the former were invalidated.

It did so though by retrieving all logins, and filtering out those that were users based on the fact that the GUID could be recognised as one derived from an integer.

That causes the linked issue though if there are 2000+ members, as we aren't retrieving them in groups as we do usually when this situation could occur.

There's a better way though, in that we filter at the database to only retrieve the users in the first place - which we can do, as we know the prefix of the login provider.

So that's what's been applied here.

Testing

Visual inspection maybe enough here as I've repeated the testing that is described on the original PR linked above (which requires set up of an external login provider).

Release

This will need cherry-picking/re-applying for 16.

[Copilot]

Pull Request Overview

This PR optimizes the invalidation of backoffice user sessions when external login providers are removed by filtering at the database level rather than in application code. The change addresses a performance issue where retrieving all external logins (including 2000+ members) caused problems when only user logins needed to be processed.

• Filters external logins at database query level to exclude member logins using provider prefix
• Updates comments to reflect that only user sessions are being invalidated
• Removes redundant filtering logic that was previously done in application code

Comments suppressed due to low confidence (1)

src/Umbraco.Infrastructure/Persistence/Repositories/Implement/UserRepository.cs:1094

• The variable name 'userAndMemberKeysAssociatedWithRemovedProviders' is misleading since the query now only retrieves user keys due to the added WHERE clause. Consider renaming to 'userKeysAssociatedWithRemovedProviders' to accurately reflect the filtered data.

        List<Guid> userAndMemberKeysAssociatedWithRemovedProviders = Database.Fetch<Guid>(idsQuery);

[kjac]

🚀

[kjac]

Cherry-picked for V16.2 in 8cc6508