Full-text Indexing Fixes

[qqmyers]

What this PR does / why we need it: This PR addresses two problems with full-text indexing:

• Actively embargoed files which are not also restricted (or otherwise non-public) were still being full-text indexed
• Files in Globus and not 'accessible to Dataverse' were causing an exception in the log when full-text indexed due to a problem with the isDataverseAccessible method.

Which issue(s) this PR closes:

• Closes #

Special notes for your reviewer:
This PR is only a few lines, but is built on #11374 which makes many changes in this part of the code. Nominally #11374 will soon be merged, so checking the PR after that makes more sense.

The original design of the static isDataverseAccessible(String driverId) method caused the getInputStream method for Globus to return an exception rather than a null stream. However, all other possible failures return a null. In this PR, I changed it to return a null. I also added a new isDataverseAccessible() method to StorageIO that defaults to true. The Globus store overrides this to call the static method which looks up the relevant property to decide. This change is efficient for non-Globus stores and a convenience for Globus ones (in the full text indexing, we have a StorageIO class but don't have the driverId to call the static method.

Suggestions on how to test this: Add an embargoed file (not restricted), publish, check whether it's content is visible to search. To test the Globus part, reindex a dataset with Globus/NESE files, with full-text indexing on, verify that there's no null exception in the logs.

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

Is there a release notes update needed for this change?: Not sure - #11374 makes broad indexing changes - it's release note probably covers this.

Additional documentation:

[coveralls]

coverage: 23.114%. remained the same
when pulling 5e6d1a7 on GlobalDataverseCommunityConsortium:indexing_fixes
into 5db10ea on IQSS:develop.

[ofahimIQSS]

1. I came across some issues while testing globus in internal. When I try to upload files via globus to my dataset, I get a timeout error and the files aren't transferred over.
   https://github.com/user-attachments/assets/2eeaf1f2-1dc6-436c-8fea-48f58d346bb8

2. For this dataset: https://dataverse-internal.iq.harvard.edu/dataset.xhtml?persistentId=doi%3A10.70122%2FFK2%2FQZQPQE&version=DRAFT --- I am unable to publish this dataset for some reason. I hit publish then refresh after a moment - dataset still showing draft status.
   https://github.com/user-attachments/assets/fa8c9772-4ea4-4d8a-bfcb-2b0d3e828b82

Adding @landreev

[qqmyers]

1. is easy I think - the cloud where NEESTape is is down for maintenance through Wed. I would have expected Globus to just report not being done and the Globus lock staying on the dataset until the endpoint came back up on Wed. evening.

2. appears to be due to some files not having an empty string separator in the dvobject table (including for this dataset). As far as I can tell, there's a set from <~Feb. 2025. I'm not sure why that might be - possibly a bug or config issue (I think we used to have a FAKE DOI provider using the valid DataCite test authority/shoulder and I switched it this spring to use the Dataset test account when we had config issues. )? The relevant code is in

   dataverse/src/main/java/edu/harvard/iq/dataverse/pidproviders/AbstractPidProvider.java

   Lines 209 to 217 in 9e57e73

   	if (dvObject.getSeparator() == null) {
   	dvObject.setSeparator(getSeparator());
   	} else {
   	if (!dvObject.getSeparator().equals(getSeparator())) {
   	logger.warning("The separator of the DvObject (" + dvObject.getSeparator()
   	+ ") does not match the configured separator (" + getSeparator() + ")");
   	throw new IllegalArgumentException("The separator of the DvObject (" + dvObject.getSeparator()
   	+ ") doesn't match that of the provider, id: " + getId());
   	}

   where you can see that an empty but non-null separator results in an error for a DOI where the separator for the provider is hardcoded to '/' - I see the warning shown in the log. If we think this is in any production db, we probably can/should have an issue to fix it.

In both cases, it should not be relevant to the PR and I think testing can either use new datasets (for the non-globus, embargo issue), or reindexing of earlier Globus datasets (i.e. by using the index dataset api) (to check for Globus/full text warnings).

[qqmyers]

I created a bug report - #11546 with more analysis of issue 2)

[ofahimIQSS]

Merging this - was able to finally test with globus up and running.