Closes #6380

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

I considered changing the instances database and renaming CAN_DELETE_BEFORE_SEND to a more generic CAN_DELETE, and updating the row after sending a form. However, this approach would be significantly more complex and riskier, so I decided to simply introduce a helper function #canDelete instead:

public boolean canDelete() {
        return canDeleteBeforeSend || !status.equals(Instance.STATUS_COMPLETE) && 
              !status.equals(Instance.STATUS_SUBMISSION_FAILED);
}

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?

This should only adjust how we determine which forms can be deleted. Please test this filtering thoroughly with every possible form status to ensure it works correctly.

Do we need any specific form for testing your changes? If so, please attach one.

No.

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

No.

Before submitting this PR, please make sure you have:

• added or modified tests for any new or changed behavior
• run ./gradlew connectedAndroidTest (or ./gradlew testLab) and confirmed all checks still pass
• added a comment above any new strings describing it for translators
• added any new strings with date formatting to DateFormatsTest
• verified that any code or assets from external sources are properly credited in comments and/or in the about file.
• verified that any new UI elements use theme colors. UI Components Style guidelines