Converge batch_size and concurrent_requests

[kbrock]

part of: https://github.com/ManageIQ/manageiq/pull/22510

Before

• concurrent_requests, thought it existed in core, was vmware only. It was split up into historical, hourly, and realtime.

• batch_size was per provider (but only implemented by vmware) It just has a single option.

After

• concurrent_requests defined in the provider (but only implemented by vmare) It is split up into historical, hourly, and realtime.

Reason for change

While batch_size may be 250, concurrent_requests was then applied and we were sending only 20 requests for realtime and 1 for historical.

So in the end, we only are sending 1 request to the provider. The optimization has basically been disabled.

This gives better values for concurrent requests, and matches the requests sent to the collector over the queue and from the collector to the provider

This requires changes in both vmware and core.

NOTE: these values are estimates and have not been battle tested in production. They are better than the current values though (read: 1)

[miq-bot]

Checked commit https://github.com/kbrock/manageiq-providers-vmware/commit/cca8a80d93f42f21560187faaf237bdd45bb97bb with ruby 2.6.10, rubocop 1.28.2, haml-lint 0.35.0, and yamllint 1 file checked, 0 offenses detected Everything looks fine. :star:

[kbrock]

failure: depends upon change in master

[agrare]

I was waiting on a schema PR being opened and totally missed that @kbrock put one in two days ago