Send client_id for OAuth2 registry auth

[chanseokoh]

Fixes #1545. client_id is a required parameter.

[loosebazooka]

Is there a situation where this needs to be configured? Or would the server just include "jib" as a valid client?

[chanseokoh]

My understanding is that this OAuth2 Client ID is a public identifier for an app. In our case, the app is Jib. Basically, I think we can generate whatever value we want. The spec doc says the auth server does not need to have ID registered, so I think any value will work.

My only concern is that, although the ID is public, this doc says it's a good practice to use an ID that is not easily guessable. I think I'll generate some longer string.

[loosebazooka]

It's be hard to make an unguessable client ID of we hardcore it. If we need to make it configurable in the future maybe we can deal with that then.

[chanseokoh]

Let me use an MD5 hash da031fe481a93ac107a95a96462358f9 generated from a string jib. (https://www.md5hashgenerator.com/) The ID is public, so it really shouldn't matter whether it's known. It is just that, it will be a slight deterrent if using a non-trivial ID. Like, if someone already knows an email address of someone else, it is slightly easier to attempt logging in by trying a brute-force password attack. And I think it's not really something that users want to configure.

[briandealwis]

Since it's likely the client-id will appear in the registry logs, IMHO we should use something that clearly indicates Jib — the TOOL_NAME would be best, wouldn't it?

Further discussion to be had

[chanseokoh]

Good idea. The class is in jib-core, so the TOOL_NAME is jib-core. And I think it's not worth passing down jib-maven-plugin or jib-gradle-plugin depending on the execution context. So I think I'd just have jib as a prefix: jib.da031fe481a93ac107a95a96462358f9. It's clear from the ID that the application is Jib, and as suggested in the doc above, the entire ID is not able to guess without any context.

[briandealwis]

Containerizer and BuildConfiguration provide getToolName(), but that isn't propagated into RegistryAuthenticator. We can revisit this if a need arises.