Allow publishing conditional on indexing being done, add /timestamps

[qqmyers]

What this PR does / why we need it: This PR is one way of handling the issue where publishing can fail do to OptimisticLockExceptions. This implementation adds an optional boolean query parameter to the publish API call - assureIsIndexed - that, if true, causes the call to return a 409/conflict error if indexing is pending (determined by checking both the modification/permissionmodification times against the respective indextime/permissionindextimes). Without the parameter, there are no changes to how things work.
The PR also adds a /timestamps endpoint that reports various timestamps (a subset on the latest published version only, and, if you have permission to view the draft, the complete set of timestamps for the latest/draft version). The endpoint also includes two booleans indicating whether the index /permission index is stale (earlier than the corresponding modification times). The intent with the endpoint and these booleans in particular is to make it easy to wait for indexing to finish if other calls that modify the dataset are found to have the same issue. (Nominally one could add the same query param on those methods, but this would enable a polling-based workaround without waiting for further software updates.

Which issue(s) this PR closes:

Closes #7637

Special notes for your reviewer: I think this approach is valuable for DANS/others doing automated upload/edit/publishing. Something is needed asap. That said, I'd hope that other design changes could eventually remove the need for this, i.e. if indexing did not change the Dataset/interfere with its modification by calls setting locks.

Also note that the extra logic checking for permissionmodificationtime being null is due to #7625.

Suggestions on how to test this: Should test that things work as is now with the publish api. To test the new param, the easiest approach might be to set it to true and set the index time for the dataset to null before calling publish (should result in 409/conflict). Re-indexing or setting the index time later than the modification time would then allow publish to succeed. (Alternately, one could try to create a dataset with slow indexing and call edit and then publish quickly enough to see a 409. This is essentially what DANS is doing.)

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

Is there a release notes update needed for this change?:

Additional documentation: will add docs of the new param and new /timestamps call if/when the code is approved.