Refactor and test version comments

[theosanderson]

Currently versionComments are implemented in a pretty confusing way for developers:

• versionComments can either be stored as a metadata item called versionComment or as a column called versionComment
• For revisions the first approach is used
• For revocations the second approach is used

Instead we should just use one approach :)

[anna-parker]

Just for some background I did this as a workaround because revocations have an empty originalDataColumn in SequenceEntriesTable and are not sent to preprocessing (they are filtered out in fetchUnprocessedEntriesAndUpdateToInProcessing) - so their processedDataColumn in SequenceEntriesView is always empty in the current set up. The versionComment field for revocations is therefore a special case as it is generated from user input but cannot (directly) be read from the processedDataColumn like other user-input metadata fields. As a workaround I chose to add the versionComment field in its own column and merge this column with the processedDataColumn when retrieving metadata.

Other options could be:

• Add the revocation versionComment to the originalDataColumn instead of a custom column and again have a custom merge that handles revocations and revisions differently when we get the data from the backend e.g. in the get-released-data call. -> same level of complexity
• Add the revocation versionComment to the originalDataColumn and send revocations to preprocessing so that the versionComment ends up in the processedDataColumn -> will probably require some prepro changes
• Add the revocation versionComment to the originalDataColumn and update the processedDataColumn with the contents of the originalDataColumn automatically for revocations. -> I think this is the best approach I can think of