batch-response duplicates Resource.id in Bundle.entry.response.id

[lmsurpre]

Describe the bug When I create a number of resources at once via the "batch" endpoint, I notice that the responses have the corresponding resource ids in the response.id

This is mostly fine, but I believe there is a chance for these ids to conflict if you create two different resources with different types but the same ids.

I'm not sure what value there is in setting this field to begin with, so my recommendation is to remove it from the response. Alternatively, we could set these to the internal resource id of the specific version of that particular resource (like we do in the history API).

Environment Which version of LinuxForHealth FHIR Server?

To Reproduce Steps to reproduce the behavior:

1. create a bundle of type batch with PUT entries for multiple resources with the same id
2. post the bundle to the server
3. note that the response contains multiple entries that each have the same response.id

Expected behavior Element.id values are supposed to be unique within the resource

Additional context transaction-response may have the same issue; not sure

we used to do this in a number of other spots as well (e.g. search response bundles and history response bundles), but those have been fixed:

• in the search-response case, this element has been removed
• in the history-response case, I believe that the ids are still present but they are set to the internal resource id (which is always unique to a particular version of a particular resource)

[lmsurpre]

Robin supports adding the internal resource id to these entries. That sort of makes these part of our public contract, but we already went there with our 'nextId` and 'previousId' paging parameters.