Rate limiting trace logs shows incorrect "is UI request:" parameter

Issue Summary

When we enable TRACE logging for com.atlassian.ratelimiting.internal.requesthandler, one of the entries logged shows "is UI request:" data.

It turns out that this ignores the authorization header and if the request is Basic or Bearer (token), it might show an incorrect result which can be misleading.

Reference: Jira rate limiting is not working due to cookies/headers in the requests

Notice that this bug affects trace logging only, and not the functionality itself

This is reproducible on Data Center: yes

Steps to Reproduce

1. Enable Rate Limiting
2. Enable TRACE logging to com.atlassian.ratelimiting.internal.requesthandler
3. Send a few requests so they get throttled.
   • They should be either with Basic authentication or use a token
   • They should have an Origin and Referer headers

Expected Results

The requests are throttled as expected, and the logs say

... is UI request: [false]

Actual Results

Even though the request is not considered to be UI, the logs show it is:

... is UI request: [true]

Workaround

Check the Authorization header below that message to identify if Jira will consider the request for throttling.
More details at Jira rate limiting is not working due to cookies/headers in the requests