Fcrepo 2975 - Create timemap when resource created

[bbpennel]

JIRA Ticket: https://jira.duraspace.org/browse/FCREPO-2975

What does this Pull Request do?

Resolves an NPE when committing transactions containing HEAD and DELETE requests to the same resource by creating timemaps at the same time that the original resource was created.

What's new?

Creating timemap at the same time that a resource is created.

• Implemented TimeMapService for the creation of timemaps
• Changed FedoraResourceImpl.getTimeMap() to never create timemaps
• Allow for responses for versioning disabled resources to not return a timemap uri
• Moved constant for fedora:timemap node to constants class for consistency and since it did not primarily belong to FedoraResourceImpl anymore.
• Added and updated tests

How should this be tested?

See example in ticket as well as new integration tests.

Additional Notes:

This changes the approach in fcrepo5 regarding when timemaps are created from lazy-creation to explicit creation at object creation time.

Interested parties

@awoods @dbernstein

[dbernstein]

@bbpennel : This looks good to me and it works as advertised. Thanks for the quick turn around time.
Just curious: did you see/consider any other ways of preserving the lazy timemap creation? I know we went that root for the sake of performance (although I don't know if we ever quantified the time saved by using lazy time map init.

[bbpennel]

@dbernstein I didn't explore other options too much. The previous implementation was actually creating the time map at the end of the request to create the original resource because of the getTimeMap() call here https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-http-api/src/main/java/org/fcrepo/http/api/ContentExposingResource.java#L549
But the created timemap was not being saved, so every request to the resource would create the resource again. The timemap only became real when a version of the resource was created because it was committed in that case.

I did consider explicitly committing the session after the lazy creation would have happened here:
https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-http-api/src/main/java/org/fcrepo/http/api/FedoraLdp.java#L696
But thought that might seem odd and more likely to get undone in the future since retaining the timemap required a second seemingly unrelated step (session.commit())

The other component was that I agreed with @awoods that it seemed undesirable for a HEAD request to make changes to a resource, an unexpected side effect which was partially causing the bug in this ticket. I'm not sure if the head request caused time stamps to change, didn't attempt to verify that.

[dbernstein]

@bbpennel : thanks for the explanation. That all makes a lot of sense.