[8.x] "null" constraint prevents aliasing SQLite ROWID

[Max13]

On SQLite, columns are nullable by default. Adding null forcibly, prevents users aliasing ROWID and will create another (autoincrementing in some cases) column and it's overhead in calculation (see: SQLite ROWID and the INTEGER PRIMARY KEY)

To summerize SQLite documentation: by default, every table has a rowid column, which already is an INTEGER (64bits), is autoincrementing (not always by 1) and is unique across the table. When a column type is exactly INTEGER and a PRIMARY KEY, then this column is an alias of rowid. When the column type is INTEGER NULL, INT, BIGINT or anything else, it's a totally different column.

This change should be backward compatible as columns are nullable by default anyway.

[Max13]

@taylorotwell Regarding this "issue", would it be a good idea to alias $…Increments() column to ROWID anyway?

Currently, with this PR merged, to use the internal rowid as primary key aliased, the user must manually use $table->integer('id')->primary() in Schema, as $…Increments() won't. If we use rowid as primary key by default, then to implement another primary key, with AUTOINCREMENT or with another affinity then INTEGER, then users will have to use a specific syntax. As it would be a breaking change, I consider this for the next major.

[driesvints]

@Max13 it's unlikely Taylor will see that message. Best that if you want to propose something that you send in a PR so we can look at the code.

[Max13]

@driesvints Thanks for the input. Then I prefer asking on discord because I don't consider it a breaking change, other members might. Then depending on this status, it should be sent to 8.x or master. And ultimately, it can also be rejected so by asking I may have other inputs and ideas.