Cleartext submissions can be accepted to an encrypted form

[lognaturel]

Two scenarios:

• The form was published without encryption, clients got form definitions without encryption keys. Then encryption was added but clients may still have the old form def and make submissions from it.
• Cleartext submissions are sent through the API without going through a client that honors the encryption key. E.g. non-finalized instances (so non-encrypted) are pulled from Collect and submitted via Briefcase.

@issa-tseng makes the point at getodk/central-backend#298 (comment) that submissions are already transmitted in cleartext so perhaps rejecting is low-value. However, the biggest (only?) reason encryption is used is because the server or some subset of users who have access to it can't be fully trusted. With Aggregate it was sometimes about the transport (because HTTP was easy) but with Central, I don't think it would be.

There are also a couple of practical concerns:

• Can Central correctly produce an export from a mix of encrypted and non-encrypted submissions? (probably)
• Can Briefcase? (probably not)

If it's relatively low effort, my preference would be to reject non-encrypted submissions when the published form definition requires encryption. If it's more than a couple of hours of effort we can close and come back to it if users run into problems.

[issa-tseng]

Can Central correctly produce an export from a mix of encrypted and non-encrypted submissions? (probably)

yes. it does already.