Login api request frequently when disabled auth with 2.x client.

[KomachiSion]

Describe the bug
When disable auth and use 2.x client with username and password. The login API will be request frequently, and the login API high using CPU to do BCrypt.

The problem is caused by the enhancement after 2.2 I think, when auth diasbled, the server will return empty token and the 2.X client will think the empty token is illegal and do retry after 5s.

Expected behavior
login API request by normally.

Actually behavior
login API request by frequently.

How to Reproduce
Steps to reproduce the behavior:

1. start server with auth disabled.
2. run example with username and password
3. see CPU used and prometheus api request monitor.

Additional context
In fact, the right usage is no config username and password. But we can force users to remove the config.
So I think community can do some enhance to reduce these problem.

1. Maybe can cache the BCrypt hash with the raw password to reduce the BCrypt called. (The most cost in BCrypt.encipher)
2. Client login enhance, should client to judge the token context illegal? I think only need to judge api code and the token field whether contain.

[KomachiSion]

Current bug has simple fixed by #11495 .

Next version server will return AUTH_DISABLED as token when auth disabled to make client no get empty token to retry login.

[KomachiSion]

And I see the BCrypt check logic, It seems no normal way to do this cache.
Because BCrypt check method need input raw and hashed String. Although we can call encode to generate the BCrypt string again, but the equalsNoEarlyReturn is not public method. server can't call this method to check cached string directly. Need use MessageDigest.isEqual(byte[], byte[]) directly.

So maybe community need to discuss whether use this solution.

[KomachiSion]

And for client logic, I see the old version client like 1.4.X. The token only check response status and token field exist.

I think new version client should follow old logic.
In fact, client no way to judge the token content is invalid or not.

[309283175]

JwtTokenManager{
       public String createToken(String userName) {
        //if (!authConfigs.isAuthEnabled()) {
            //return StringUtils.EMPTY;
        //}
        checkJwtParser();
        return jwtParser.jwtBuilder().setUserName(userName).setExpiredTime(this.tokenValidityInSeconds).compact();
    }

    public long getTokenTtlInSeconds(String token) throws AccessException {
        if (!authConfigs.isAuthEnabled()) {
            //TimeUnit.MILLISECONDS.toSeconds(System.currentTimeMillis())+tokenValidityInSeconds;
            return tokenValidityInSeconds;
        }
        return jwtParser.getExpireTimeInSeconds(token) - TimeUnit.MILLISECONDS.toSeconds(System.currentTimeMillis());
    }
}

需要正常返回登录token以及ttl，
目前的算法未开启鉴权返回的ttl导致客户端ttl超时需要48年，让我的测试环境不重启无法再取到token

[KomachiSion]

JwtTokenManager{
       public String createToken(String userName) {
        //if (!authConfigs.isAuthEnabled()) {
            //return StringUtils.EMPTY;
        //}
        checkJwtParser();
        return jwtParser.jwtBuilder().setUserName(userName).setExpiredTime(this.tokenValidityInSeconds).compact();
    }

    public long getTokenTtlInSeconds(String token) throws AccessException {
        if (!authConfigs.isAuthEnabled()) {
            //TimeUnit.MILLISECONDS.toSeconds(System.currentTimeMillis())+tokenValidityInSeconds;
            return tokenValidityInSeconds;
        }
        return jwtParser.getExpireTimeInSeconds(token) - TimeUnit.MILLISECONDS.toSeconds(System.currentTimeMillis());
    }
}

需要正常返回登录token以及ttl， 目前的算法未开启鉴权返回的ttl导致客户端ttl超时需要48年，让我的测试环境不重启无法再取到token

welcome new issues and new PR.