Panicking when a write txn tries to free a page which was allocated by itself

[ahrtr]

A writing TXN should never free a page which was allocated by itself.

Link to #789

[tjungblu]

testcase that triggers this panic:

https://github.com/etcd-io/bbolt/compare/main...tjungblu:cache_freelist_inconsistency?expand=1#diff-3d69c5fb9cdafd3a4e75384354f4a9e14b5318b0e4ec549000cfebd1ac3c6b1bR183-R202

[ahrtr]

https://github.com/etcd-io/bbolt/compare/main...tjungblu:cache_freelist_inconsistency?expand=1#diff-3d69c5fb9cdafd3a4e75384354f4a9e14b5318b0e4ec549000cfebd1ac3c6b1bR183-R202

line 194, it tries to free a page which was just allocated by itself. You can do this in a unit test, but actually it will never happen in real production use case.

f.free(common.Txid(2), common.NewPage(allocate, common.LeafPageFlag, 0, 1))

[tjungblu]

I'm not saying it's a production issue, I was merely testing all the branches ;-)
If it's not allowed, the panic is the correct way to continue with this.

[tjungblu]

/lgtm

[ahrtr]

Just rebased this PR, PTAL @fuweid @tjungblu

[tjungblu]

still looks good!

/lgtm

[ahrtr]

Just rebased this PR, PTAL @fuweid @tjungblu

[tjungblu]

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ahrtr, fuweid

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [ahrtr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment