[core.savedObjects] Expose PointInTimeFinder as a helper for paging through SOs

[lukeelmers]

In #89915 we introduced a PointInTimeFinder to make it easy to iterate over large numbers of saved objects using pit and search_after.

Currently this helper is only used internally by the SavedObjectsExporter, however we think it would be beneficial to expose this somewhere public as the logic is easy to mess up (for example, forgetting to close a PIT right after you are done with it could have detrimental effects on your cluster).

Depending on where it lives, the usage may need to be adjusted somewhat, but my immediate thought would be to put it in the saved objects client itself:

 const findOptions: SavedObjectsFindOptions = {
   type: 'visualization',
   search: 'foo*',
   perPage: 100,
 };

 // instead of requiring a logger we can probably inject one,
 // and we'll already have access to `find` from the client itself
 const finder = savedObjectsClient.createPointInTimeFinder({ findOptions });

 const responses: SavedObjectFindResponse[] = [];
 for await (const response of finder.find()) {
   responses.push(...response);
   if (doneSearching) {
     await finder.close();
   }
 }

An alternative would be exporting it as a static helper as it is currently used internally, which would require a logger and savedObjectsClient to be provided by the consumer. However, I think it might be nice to be able to keep the logs together under the savedobjects-service context, rather than having them attached to any arbitrary logger a consumer provides.

WDYT @pgayvallet @rudolf?

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[pgayvallet]

An alternative would be exporting it as a static helper as it is currently used internally

I strongly think that exposing this an an API from the SO client is way better that a static helper.

The suggested

const finder = savedObjectsClient.createPointInTimeFinder({ findOptions });

looks great to me. We may just want to restrict some of the options of SavedObjectsFindOptions for this API, as manually providing a pitId wouldn't make any sense for example.