Wallet gRPC authentication is nonstandard

[AaronFeickert]

The handling of wallet and node gRPC authentication is somewhat nonstandard:

• The server configuration contains plaintext credentials.
• The user is provided with a PHC string representing the Argon2 hash of the password.
• The client (miner/proxy) configuration is updated with the PHC string.
• When authenticating, the client provides the username and PHC string in an HTTP basic authorization header.
• The server applies Argon2 to its plaintext password as part of verification.

My understanding had been that this was an intended design choice, given the local threat model. However, it appears that this isn't the case. With ongoing work to support TLS connections for gRPC operations, and recent work adding base node gRPC authorization, the design should be updated to a more standard approach.

The usual PBKDF threat model assumes compromise of the server's password store, and wants to limit the ability of the attacker to determine a password. This isn't really the case here. One design approach could simply be a static shared high-entropy token that the server and client both store, and which is simply checked in constant time during authorization. This is unwieldy and less in line with the idea of HTTP authorization, so a standard username/password approach could still be used to keep things simple for the user.

The design could be the following:

• Plaintext credentials are supplied during gRPC server setup.
• The password is processed with Argon2, and its PHC string is stored locally along with a username (which could be blank or a default if desired).
• The client specifies the password in an HTTP header, read either via configuration or environment variable or runtime options.
• The server verifies the supplied password against its stored PHC string as part of verification.

There are still other considerations and risks with this:

• If the HTTP connection isn't otherwise protected, a passive attacker can simply sniff the password on the wire.
• If the client is compromised, an attacker can read the plaintext password from configuration or environment variable or runtime logs.

[AaronFeickert]

This is related to #5809.