x-pack/filebeat/i.../entitya.../.../okta: Avoid a negative request ra…

…te (#40267) (#40460)

This is the minimal change necessary to fix the following problem.

Around the time of a rate limit reset, if current time is after the
reset time returned in response headers, the rate limiting code will
set a negative target rate, and if that's done at a time when no
request budget has accumulated, it will not recover and will wait
forever.

CHANGELOG.next.asciidoc

@@ -98,6 +98,7 @@ https://github.com/elastic/beats/compare/v8.8.1\...main[Check the HEAD diff]
 - Prevent GCP Pub/Sub input blockage by increasing default value of `max_outstanding_messages` {issue}35029[35029] {pull}38985[38985]
 - Updated Websocket input title to align with existing inputs {pull}39006[39006]
 - Relax requirements in Okta entity analytics provider user and device profile data shape. {pull}40359[40359]
+- Fix bug in Okta entity analytics rate limit logic. {issue}40106[40106] {pull}40267[40267]
 
 *Heartbeat*
 

x-pack/filebeat/input/entityanalytics/provider/okta/internal/okta/okta.go

@@ -380,7 +380,7 @@ func oktaRateLimit(h http.Header, window time.Duration, limiter *rate.Limiter) e
 	rateLimit := rate.Limit(rem / per)
 
 	// Process reset if we need to wait until reset to avoid a request against a zero quota.
-	if rateLimit == 0 {
+	if rateLimit <= 0 {
 		waitUntil := resetTime.UTC()
 		// next gives us a sane next window estimate, but the
 		// estimate will be overwritten when we make the next