Migrate sync journal table structure to support BIGINT switch on server's DB

[SamuAlfageme]

Once support for big fileids (owncloud/core#26901 & owncloud/core#28364) is merged in core, we'll need to review the way the client stores the fileids on the sync journal.

Also, review the impact this switch might have in the private link feature: #5763 - I remember there was some intermediate step for filling the id with zeroes in #5763 (comment), maybe we now need more padding (?) cc/ @ckamm

In owncloud/core#26901 (comment) there's a list of all affected columns on the server's DB.

[guruz]

At least three things to it:

• Our C layer (ex-csync)
• Our C++/Qt layer (propagation)
• The sqlite3 DB ("INTEGER. The value is a signed integer, stored in 1, 2, 3, 4, 6, or 8 bytes depending on the magnitude of the value.")

[ckamm]

BIGINT is roughly an 8 byte integer on MySQL, MariaDB and PostgreSQL. So our sqlite layer is already safe. We do need to go through the code and ensure we use a fitting datatype though. And yes, the conversion from fileid to id needs a double check to be in line with what the server does.

[ckamm]

On further investigation, the client is already fully prepared for this change. We store the full id as text in the database and extract the numeric id (as text) from it.

I've commented about potential effects on the full id at owncloud/core#26901 (comment) . Once that receives an answer, I'd add a unittest and close this issue.

[ckamm]

I've also tested with master owncloud server by manually assigning a fileid beyond the 4-byte range in the servers database. The client database looks fine and the link generation works.