fix: EXPOSED-108 Incorrect mapping for UInt data type

[bog-walk]

Related to PR #1799

Current State of UIntColumnType (excluding MySQL/MariaDB):

When attempting to insert a UInt value outside of the range 0..Int.MAX_VALUE, Exposed first truncates the value by calling value.toInt() before sending it to the DB:

object UIntTable : Table("uint_table") {
    val unsignedInt = uinteger("uint")
}

transaction {
    UIntTable.insert { it[unsignedInt] = 3_221_225_471u }  // compiles OK because it is a UInt
    // but generates SQL:
    // INSERT INTO uint_table (uint) VALUES (-1073741825)
}

The value is successfully stored as a negative number because most databases don't support unsigned types natively, which means Exposed is actually mapping UInt to 4-byte INT, which accepts the range -2^31..(2^31)-1. The value returned from the DB is the negative overflow and an IllegalStateException is thrown by valueFromDB().

Note: The compiler will prevent a negative number from being assigned to it[unsignedInt], but there is nothing stopping the DB from storing a negative number that is inserted directly using raw SQL:

exec("""INSERT INTO uint_table ("uint") VALUES (-1073741825);""")  // success with no SQLException
// only throws IllegalStateException if attempting to retrieve data

Solution:
Change the column type in the DB to use the next higher type, BIGINT in this case, and add a check constraint when uinteger() is registered. This would ensure that only UInt values are accepted, even if raw SQL is used.

Exception:
[Oracle] The type has not changed because it was already set to NUMBER(13) (versus the INT alias for NUMBER(38)), but a check constraint has been implemented.

Saving Storage Space:
While using a larger numeric type with a check constraint is a common solution for supporting unsigned integers, some users may not want to use 8 bytes of storage for every number. If the end-goal of the user is a column that only uses 4-bytes but does not allow negative values and they know for a fact that inserted data won't exceed Int.MAX_VALUE, then the recommendation should be to use a integer() column with a manually created check constraint:

integer("number").check { it.between(0, Int.MAX_VALUE) }
// OR
integer("number").check { (it greaterEq 0) and (it lessEq Int.MAX_VALUE) }