Improve JWK messages

[1000TurquoisePogs]

This is a PR that takes a pragmatic approach about that we know what follow-up troubleshooting certain JWK error messages involve, so we should just print more about what happened and what the user can do about it.

[JoeNemo]

Approved.

[Martin-Zeithaml]

Probably needs fflush(stdout); after the zowelog. Otherwise I can see message header after the text:

"possible error message"JWK response:

instead of

JWK response:
"possible error message"

[ifakhrutdinov]

On top of that, the message might get split by some other stray message since they're not printed as a single message.

[ifakhrutdinov]

See my recommendation (I also incorporated them in a commit, which has only been build-tested).

[ifakhrutdinov]

I suggest we have a single messages: Server will not accept JWT\nCheck URL %s for errors.\n and format the path in a separate function. The reason for that is for a simple task (print an error message) we're spilling so much unnecessary details here and in jwkTaskMain; it's better to isolate that.

[ifakhrutdinov]

I'd add a helper function and simplify this code:

static char *printJWKURL(const JwkSettings *settings, char *buffer, size_t bufferLen) {
  int charsPrinted;
  if (indexOf(settings->host, strlen(settings->host), ':', 0) != -1) {
    charsPrinted = snprintf(buffer, bufferLen, "https://[%s]:%d%s", settings->host, settings->port, settings->path);
  } else {
    charsPrinted = snprintf(buffer, bufferLen, "https://%s:%d%s", settings->host, settings->port, settings->path);
  }
  if (charsPrinted < 0) {
    memset(buffer, 0, bufferLen);
  }
  return buffer;
}

static int jwkTaskMain(RLETask *task) {
...
  if (success) {
    zowelog(NULL, LOG_COMP_ID_JWK, ZOWE_LOG_INFO, ZSS_LOG_JWK_READY_MSG, settings->fallback ? "with" : "without");
  } else {
    char url[256];
    zowelog(NULL, LOG_COMP_ID_JWK, ZOWE_LOG_WARNING, ZSS_LOG_JWK_FAILED_MSG, printJWKURL(settings, url, sizeof(url)));
  }
...
}

[1000TurquoisePogs]

This looks to make the code more complicated. Why do this?

[ifakhrutdinov]

Why do this?

Because it's not more complicated?

In the current implementation, you mix lower and higher level logic, and then you have to introduce additional message templates just to work around the peculiarities of IPv6; this all basically unnecessarily spreads lower level details over a larger area than needed.

So, why not just hide this in a specialised function which can be easily reviewed and verified?

[ifakhrutdinov]

On top of that, the message might get split by some other stray message since they're not printed as a single message.