Alter entity spec version and add branchId, trunkVersion in form schema

[ktuite]

Closes getodk/central#692

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

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

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.yaml as part of this PR.

Before submitting this PR, please make sure you have:

• run make test 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]

Just small comments, this is looking good to me. 👍 I haven't taken a look at tests yet, but maybe we could do that interactively.

[matthew-white]

We'll need to account for this new action on Frontend. I'd be happy to do so if that'd be helpful.

[ktuite]

Interactive review with @matthew-white

[matthew-white]

I think I'm realizing that there's a subtle thing happening here with publishedBy, which the API returns on the form def/version. I think the API only returns publishedBy with extended metadata and only from the version list endpoint (…/versions), though I could be wrong about that. But my suspicion is that if the worker job in this PR creates a new published version, then publishedBy will end up being null. In the past, I don't think it's been possible for publishedBy to be null.

I actually don't think that Backend will have any issue with publishedBy being null. For example, the SQL query for publishedBy is already a left join. That said, I think it's probably worth verifying in a test that publishedBy is null for an [upgrade] form def.

I also don't think that Frontend will have an issue with publishedBy being null. It looks like the FormVersionRow component is the only one to reference publishedBy, and it will work fine if publishedBy is null (it just won't show it).

I don't think anything needs to change here except for maybe adding a test. But I wanted to note this as a slight change in thinking about publishedBy, that there's now a concrete case in which it can be missing.

[ktuite]

I think I'm realizing that there's a subtle thing happening here with publishedBy, which the API returns on the form def/version. I think the API only returns publishedBy with extended metadata and only from the version list endpoint (…/versions), though I could be wrong about that. But my suspicion is that if the worker job in this PR creates a new published version, then publishedBy will end up being null. In the past, I don't think it's been possible for publishedBy to be null.

It looks like

• publishedBy is not present on the .../forms/xmlFormId request, just createdBy and publishedAt.
• publishedBy is null for the version published by the worker (only accessible through /versions with extended metadata)
• It's also null in the audit log (probably why it is null in versions), which seems appropriate