Add API to support saving local only resources

[ndegwamartin]

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).

Fixes #2123

Description Clear and concise code change description. See #2123

Alternative(s) considered Have you considered any alternatives? And if so, why have you chosen the approach in this PR? See #2123

Type Choose one: (Bug fix | Feature | Documentation | Testing | Code health | Builds | Releases | Other) Feature

Screenshots (if applicable) N/A

Checklist

• [x] I have read and acknowledged the Code of conduct.
• [x] I have read the Contributing page.
• [x] I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA.
• [x] I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach.
• [x] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project.
• [x] I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally.
• [x] I have built and run the demo app(s) to verify my change fixes the issue and/or does not break the demo app(s).

[ndegwamartin]

@aditya-07 could you have a second look to see if this is what you had in mind?

[ndegwamartin]

@jingtang10 you had a concern with the updates for the related resources processed by the implementation here, could you share that here or on the ticket #2123 ?

[ndegwamartin]

From this line - ResourceDao.kt#L250 it appears that the database API actually performs an upsert.

[jingtang10]

From this line - ResourceDao.kt#L250 it appears that the database API actually performs an upsert.

what do you mean? why does this matter?

i think we still need to make db change first for this pr to work properly. i.e. creating a new column to indicate local only resources.

[ndegwamartin]

From this line - ResourceDao.kt#L250 it appears that the database API actually performs an upsert.

This was a response to Aditya's comment and feedback from the discussion last time but essentially in the current implementation the API can cater for both Creates and Updates, we'd just need to rename the method to reflect this.

Delete of course would still not be handled hence why we are exploring the db change option to capture all ops.

[ellykits]

It would be good to get into the use cases and what we would like to support initially. It is not very clear from the issue https://github.com/google/android-fhir/issues/2123 as to why this might be needed. eg: Multiple FHIR servers, to simplify peer to peer sync strategies, save resources that are incomplete eg: a Questionnaire partially filled

The use case @ndegwamartin was attempting to address is where we'd want to download particular resources from the server (which might have been generated from other sources) to the Android client but prevent the app from uploading any changes made on these resources to the server. For instance Questionnaires, StructureMaps, Binary resource etc as used in OpenSRP.

[ndegwamartin]

Changing this to Draft for now since a workaround solution for the initial problem was put forward