Add support for detailed file info in the LuceneMetadata operation. Make metadata class API.EXPERIMENT

[ohadzeliger]

Add more info to the Lucene Index Operation metadata (file ID and size)
Make the LuceneGetMetadataInfo class EXPERIMENTAL (it is used from outside the RL).
Deprecate the metadata's file name list (users can substitute the new field to get access to the file names).

Resolves #3554

[jjezra]

There was some discussion about it, and I think that @API(API.Status.DEPRECATED) is preferred.

[ohadzeliger]

Right. I was trying to get Teamscale to not mark it as a test gap, but that didn't work.

[ohadzeliger]

Done.

[jjezra]

Can "files" here have a null assingment, and getFiles below be something like:

if (files == null && detailedFileInfos != null) {
  return detailedFileInfos.stream().map(LuceneFileInfo::getName).collect(Collectors.toList());
} 
// else return an error...

?

I assume that since files is private, the callers will always use the getFiles function to access this data.

[ohadzeliger]

Yes, we can do that, but then we will recompute the derivation every time instead of once.

[jjezra]

if (files == null && detailedFileInfos != null) {
  files = detailedFileInfos.stream().map(LuceneFileInfo::getName).collect(Collectors.toList());
  return files;
} 

?

[ohadzeliger]

I think this is exactly what constructors are doing - except that this way the class is immutable: First constructor has populates files and second constructor has files==null and detailedFileInfos != null and is therefore exactly what you have in your comment.
Since the files field is deprecated (to be removed once usage is gone), then we will be left with a simple constructor initialization.

[ohadzeliger]

I changed the constructor to take a list and added unmodifieableList to the constructor. This allows the equals method to work properly.