Have `rate_limit` return maximum values of `rate.Inf` (`math.MaxFloat64`) instead of `"inf"`

This will stop any problems caused by clients not processing `"inf"` values. An example of the currently required processing is [in `qualys_vmdr`](https://github.com/elastic/integrations/blob/6452527c1a9dfa44d54bc09ac697ac6d02e347e7/packages/qualys_vmdr/data_stream/user_activity/agent/stream/cel.yml.hbs#L121-L125).

From a [discussion](https://github.com/elastic/integrations/pull/16184#discussion_r2815861705) of this issue in a PR:

> Condition the return values from the rate limit extensions so that if either of these end up being infinite, it gets replaced with `rate.Inf`.
>
> I think this would be backwards compatible; the relevant text in the documentation is
> > The map returned by the policy functions should have "rate" and "next" fields with type rate.Limit or string with the value "inf", a "burst" field with type int and a "reset" field with type time.Time in the UTC location. The semantics of "rate" and "burst" are described in the documentation for the golang.org/x/time/rate package.
>
> This would remain true, but the second option would never happen.

Start at the rate_limit policy extensions and compare their return values with the documented policy-function fields and golang.org/x/time/rate semantics. Use the qualys_vmdr example to understand the current client workaround; done means infinite maximum values are returned as rate.Inf (math.MaxFloat64) rather than the string "inf", while other fields remain unchanged.

Written by the indexing model from the issue text.