[FEATURE] Faster loading of dynamic integrations

[Swiddis]

Is your feature request related to a problem?
For the dynamic catalog feature in #1381, integrations are loaded into the available integrations page from .kibana all at once (multiple times?), which involves sending the entire uploaded content over network repeatedly. This is less-than performant. This is an issue to address the performance issue from reading integrations.

What solution would you like?
I can think of a few potential bottlenecks, I'm not sure which is the real stopper (or how to profile it):

• Integrations are pulled multiple times for different requests, we don't implement any caching. This can be fixed by adding a cache within OSD that stores integrations read from the index.
• Assets are included entirely within integrations, making them take a lot of bandwidth. This is talked about in the separate issue [BUG] Integration assets restricted by OS 1MB upload limit #1388.
• Integrations aren't paginated/filtered in the query, which means that OS might be sending a lot of data that isn't needed. This is harder to optimize without breaking integrations down further as part of the previous issue.

What alternatives have you considered?
See above. Some or all of these can be implemented to improve the speed. I've ordered them by how much I think each issue contributes, but I haven't done the profiling to back those assumptions up.

Do you have any additional context?
N/A

[Swiddis]

Threw together a quick benchmark of the starting state and ran it locally. Gist. On my hardware (n=50):

Response Time Statistics:
Min: 0.23 seconds
Median: 0.25 seconds
Average: 0.25 seconds
Max: 0.3 seconds

If I disable index reading entirely:

Response Time Statistics:
Min: 0.0 seconds
Median: 0.01 seconds
Average: 0.01 seconds
Max: 0.02 seconds

Going to mess with optimization now.

[Swiddis]

Adding a flat in-memory cache of SerializedIntegration[]:

Response Time Statistics:
Min: 0.05 seconds
Median: 0.06 seconds
Average: 0.06 seconds
Max: 0.08 seconds

Adding an in-memory cache partitioned by integration name Map<string, SerializedIntegration[]>:

Response Time Statistics:
Min: 0.0 seconds
Median: 0.01 seconds
Average: 0.01 seconds
Max: 0.01 seconds

Seems like almost all of the performance can be solved by avoiding unnecessary repeated list iteration. Will see what I can do for a PR.

[Swiddis]

No caching but optimized network calls (seen here):

Response Time Statistics:
Min: 0.04 seconds
Median: 0.05 seconds
Average: 0.06 seconds
Max: 0.1 seconds