Submitted by: @dyemanov

Relate to DNET896

Historically, transaction ID space was limited by 2^31 transactions (started since the database creation time). After that point, the database becomes unavailable until backup/restore is performed, which resets the transaction ID back to zero. Initial Firebird 3.0 version increased the transaction ID space to 2^32 transactions which doubles the database uptime without backup/restore.

This improvement request is about shifting that limit even further.

Firebird 3.0 RC1 introduces 48-bit internal transaction IDs that are publicly (via API and MON$ tables) represented as 64-bit numbers. This makes the new limit roughly equal to 2.8*10^14 transactions, later it could be extended up to the 2^63 limit. The implemented solution has no additional storage overhead until the transaction counters grow beyond the 2^32 boundary.

While being there, attachment IDs and statement IDs were changed to 64-bit numbers (both internally and externally).

Commits: 1ae6a9b 4e4d800 FirebirdSQL/fbt-repository@157dc9b FirebirdSQL/fbt-repository@4642bd0

====== Test Details ======

Database with Tx counters about 2.8*10^14 can not be prepared at reasonable time.
Direct updating of .fdb file (its TIP page) can lead to server crash after attempting to connect - so this ticket can not be tested by using fbtest.