lmdbpool: Check Txn.ID() when a Txn is being put back into the pool
lmdbpool: Check Txn.ID() when a Txn is being put back into the pool

It was found out that this is more important than checking when a Txn is
removed from the pool because that Txn will have its stale pages
released when Txn.Renew() is called.

So the only concern when a new transaction is committed is outstanding
Txn objects (which are now taken care of which this patch) and Txn
objects soaking in the pool with stale pages.

It is not clear what cost attempting to deal with Txn objects in the
pool at the time of an update would have.  Some applications will run
optimally with the current behavior, which does nothing to Txns in the
pool and defers to their finalizers or a goroutine that which will call
TxnPool.BeginTxn() in the near future.

Neither is it clear what cost the current behavior incurrs for
write-heavy applications (or applications with write-heavy bursts).  It
may be that finalizers run fast enough (and updates commit slowly
enough) that there is no need for action on stale Txns in the pool.

bmatsuo/lmdb-go,bmatsuo/lmdb-go