Passwords shorter than 8 characters migrated from v1 fail (without any user hint) when using v1 auth in v2

Hi.

I've just been caught by a nasty issue when migrating from InfluxDB v1 to v2.

The migration script created the v1 auths and the DBRP mappings as expected but I couldn't connect using v1 credentials.

After hours of troubleshooting, I think I found the reason for that.

InfluxDB v2 enforces a minimum of 8 characters for passwords. I discovered this when trying to create a new v1 auth:

influx v1 auth create -o my-org --username test --password test --read-bucket xxxxxxxxxxxxxxx
Error: failed to set password for "test": 400 Bad Request: passwords must be between 8 and 72 characters long

It appears passwords created with InfluxDB v1, even if shorter than 8 characters, are silently migrated but using them results in an authorization error:

{"code":"unauthorized","message":"Unauthorized"}

Using a password from v1 that is longer than 8 characters works fine.

There might not be an ideal solution to this.

I'd be tempted to say that the constraint should be enforced only upon creation and short passwords from v1 should work.

If this is not possible, then the migration script should error or at least warn about it.

Until then, a more explicit error would be nice. Not sure how feasible that is.

__Environment info:__

InfluxDB 1.8.10
InfluxDB 2.7.10

Start by reproducing the migration from InfluxDB 1.8.10 to 2.7.10 with a v1 password shorter than eight characters, then verify the resulting v1 authentication failure. Review the migration script and v1 auth creation path to determine whether the completed behavior should be a migration warning, an error, or a more explicit authorization message.

Written by the indexing model from the issue text.