Remove use of submissionCreate from entity audit event

[ktuite]

Frontend part of issue getodk/central-backend#1036 and backend PR getodk/central-backend#1072.

It used to be that entity events that were triggered by a Submission (e.g. entity create OR update) would return

• sourceEvent (the actual event that caused the entity update, whether it was a submission approval, or submission creation, etc.)
• submission (the Submission object, but only if a Submission was part of the event AND the Submission was not deleted)
• a submissionCreate object for the Submission (if a Submission was part of the event) that had enough historical information including the creation time and instance ID to describe the Submission even if it was deleted.

The big change for getodk/central-backend#1072 was to remove submissionCreate and always return some kind of Submission object, either the full details, or the instance ID, submitter, and timestamp.

Flavors of frontend changes:

• Switch from looking for submissionCreate to know if the event was related to a submission to just looking for submission.
• Switch from looking for submission to know the submission was not deleted to looking for submission.currentVersion
• submission and event are contained within an entity audit event's details nested under source and all entity events have a source, though if its an API event, the source is just {}

Basic details of an Entity shows the source submission, and because this isn't returned with the Entity itself (though maybe it should be), the basic details component waits for the audit log and checks the entity's creation event for a source submission.

What has been done to verify that this works as intended?

Tests.

I was thinking about refactoring tests to have more of them use extendedEntities.createSourceSubmission but existing tests have such specific setups I was finding it hard to refactor.

Why is this the best possible solution? Were any other approaches considered?

We've long talked about removing this event detail and using different information instead.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

Could change how entity events appear on frontend, but it shouldn't.

Does this change require updates to user documentation? If so, please file an issue here and include the link below.

Before submitting this PR, please make sure you have:

• run npm run test and npm run lint and confirmed all checks still pass OR confirm CircleCI build passes
• verified that any code or assets from external sources are properly credited in comments or that everything is internally sourced

[matthew-white]

Looks great!