Be able to pull entity version source details from def source table

[ktuite]

I came across this when I was trying to check entity sources created via bulk import.

In the /versions endpoint, the source of each def was getting populated from the audits table, which in general is a good idea.

1. we already have audits around to determine some last conflict resolved event
2. the entity audits query does a bunch of work to fill out the most complete details about an event source, including full submission if it exists, backup submission details if it doesn't, and the corresponding event.

But, we're about to have entity defs that don't have a single audit event (unless they do/will?) associated with their creation, because one event will likely be shared across multiple new entities.

We have a way to directly look up an entity def's source, so I added that to the main entity def query. If there are no other source/event details to provide, it will fall back to the details directly in the source table.

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

Tests

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

I thought getting an entity def source via audits was odd when we had it directly, but then i realized how much more detailed that way of doing things is so i left it in place and added this fallback to the more basic source details. I don't think it harms anything and we can come back to "what kind of events should exist for bulk actions".

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?

Does this change require updates to the API documentation? If so, please update docs/api.md as part of this PR.

Before submitting this PR, please make sure you have:

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

[matthew-white]

we're about to have entity defs that don't have a single audit event (unless they do/will?) associated with their creation, because one event will likely be shared across multiple new entities.

A single event that's shared across multiple entities sounds nice to me.

[matthew-white]

event

Doesn't the entity def source also link back to the event? Or does getting information from that event require an additional join? Maybe TBD depending on how the bulk upload work goes?

[matthew-white]

Not sure how clear that comment was. 😅 Basically I'm wondering whether the entity def source should surface information not just from its details, but also the event that it links to. I feel like if an entity def response has a source property, it should always have a source.event property, as well. But that's also something we can figure out later.

[ktuite]

Yes, the entity_def_sources table links back to an event auditId. We could definitely include more of the event's details any time we returned an entity source. I think that will be useful when we want to show the feed for an entity and there's not a single event linked to that entity to look up via the audits, but the event can be found via the entity version. We could think about this for issue getodk/central#583.

But at least in this case (where the audits are fetched in a separate query), that entity audit query has all the extra query logic for building out the full submission and don't really want to duplicate that anywhere else.