tmstmpvfs: fix small tmstmpvfs issues

[fserb]

tmstmpvfs: fix small tmstmpvfs issues

Since we are using this, it's probably good to do some fixes:

1. fclose log FILE* in tmstmpLogFree to prevent fd leak.
2. write salt1 into tag bytes 13-15 only, preserving flag byte at 12.
3. use 1-based page number in rollback-mode ELOG_DB_PAGE events.
4. correct Hinnant era divisor from 147097 to 146097. This has been
already checked and upstreamed with sqlite.
5. close sub-file on NOMEM in tmstmpOpen instead of leaking it.

Updates tailscale/corp#36170

[bradfitz]

Upstream changes to SQLite first and then we can pull them in.

[bradfitz]

Elaborating, since you want me to elaborate more: without a lot of diligence maintaining a fork (I speak from experience maintaining our tailscale/go fork for the past 6 years), it's very easy to screw up and lose patches when rebasing later, or forget to upstream them. In tailscale/go we keep issues open for every patch we maintain and track their upstreaming status, and use those to rebase every 6 months.

I don't want to do that here again. We can just upstream changes to SQLite quickly and then pull them in.

[fserb]

I agree with the sentiment, will try to figure out how to do it.

My one point would be that even though there's nothing on this list that is actively dangerous, those bugs are being rolled out in prod right now, and we do have the other 2 things that we already merged (but were more problematic).

I'll reach out to sqlite and try to upstream this and the other changes.

[bradfitz]

Okay, you guys do what you want here. I'm off to vacation so I withdraw any objections for the next few weeks :)

I suggest you file bugs in this repo for each patch we're carrying, though, so we can spot check that the fixes remain in the future after any rebases. (One issue per logical fix) Then keep the bugs open and maybe label them a certain way. In the other repo we use label "tsgo".