It’s quite similar to what my file was like (except it was dumped from postgres), isn’t it lunny? 
I have no clue about the reason of the problem, but I would bet that there’s a new (mandatory) column in the > 1.7 that wasn’t there in the 1.6 (just a wild guess).
To me, the problem seems more like a variable type conversion failing.
And my guess would be on the config field. You can see at the beginning of my dump that empty variables are stored as {}, and at the end of the dump, they are stored ad NULL.
I would also guess that {} values were stored using gitea version<1.6, as I started using gitea several years ago, and that NULL values are stored using gitea version==1.6.
But all that are only guesses.
should be
{“AllowMerge”:true
don’t know why it changed.
Good catch ! 
Unfortunately, I am not sure it can be corrected with a simple SQL query, since it’s a json field inside the SQL row. 
I don’t know sqlite command off top of my head but in mysql it would be:
UPDATE repo_unit SET config = replace(config, '"AllowMerge":1', '"AllowMerge":true');
And as a sidenote as postgresql has native json operations it would be much easier than using a find and replace such as above.
Here is what I have done on my sqlite database:
UPDATE repo_unit SET config = replace(config, '"AllowMerge":1', '"AllowMerge":true');
UPDATE repo_unit SET config = replace(config, '"AllowRebase":1', '"AllowRebase":true');
UPDATE repo_unit SET config = replace(config, '"AllowSquash":1', '"AllowSquash":true');
just to be sure the other fields do not end up with the same error.
Now, I am able to start gitea in latest version (1.7.x) without error.
Many thanks for the help !
@Mageti this is fantastic news!