[11.x] Fix Bcrypt/Argon/Argon2I Hashers not checking database field for nullish value before checking hash compatibility

[localpath]

Backstory:
If we don't check for a nullish or empty value first before checking if a given $hashedValue is compatible with our apps algorithm, we'll always throw a runtime exception which means the end user won't receive the normally expected 401/422 or similar failed to authenticate, but rather a 500 server error which makes applications look broken.

Started seeing 500 errors for users attempting to login to the app after hash recheck landed in the framework. If a users password field is null or empty in the database they should receive a 401/422 or similar authentication exception/response. This has caused quite a bit of issues as you can imagine the context of a 500 level error vs a 401/422 which is expected if someone is trying to login but hasn't yet set a password.

Seems like this was an oversight in this feature being rolled out since we can see some inconsistencies and incorrect logical checks being missing or out of order in the hashing implementations.

Updates BcryptHasher ArgonHasher and Argon2IdHasher Hash implementations to correctly check if the $hashedValue field being checked for Hash Algorithm compatibility is not null or of length 0. This gives us the behavior before hash verification was added to the framework that will trigger the framework to return early with a proper response of false as opposed to a generic RuntimeException being thrown for a value that should never have been checked for hash algorithm compatibility.

To reproduce:

1. Install Laravel 11.x and use Fortify or your flavor of starter authentication
2. Create a user
3. Set the users password field to null in the database
4. Attempt to login with any password that meets the auth validation you have in place
5. See a 500 level error response because of the missing statements being added here

To show original behavior:

1. Repeat above 1-5
2. Add HASH_VERIFY=false in your .env
3. Attempt to login with the database password field still null
4. See the framework issue the original, correct authentication failed response

Thanks for all you do and hopefully this makes it in the framework!

[localpath]

seems like a logic error to check for the hash compatibility before checking if the hashed value is even non-null or empty.

the original if statement would never be reached. contrast to the other hashing implementations that were missing this entirely

if (is_null($hashedValue) || strlen($hashedValue) === 0) {
            return false;
        }

[localpath]

if we don't check for a nullish or empty value first, we'll always throw a runtime exception which means the end user won't receive the normally expected 401 or similar failed to authenticate, but rather a 500 server error which makes applications look broken

[driesvints]

cc @valorin