New id fields (keystonejs#5947)

* Id field experimenting

* word

* Try a different default to see what our tests do

* Update things

* snapshots

* Update things

* Remove a thing

* field view

* Fix ts errors

* WIP

* Fix a thing

* Fix more tests

* Fix things

* Fix more things

* More fixes

* Reorder a thing so the failing output is easy to debug

* Try a thing

* Update schemas

* Tests

* Update docs

* Add uuid dep

* Changeset

* Words

* Add another changeset

* Some more tests and cuid change

* Update docs/pages/docs/apis/config.mdx

Co-authored-by: Tim Leslie <timl@thinkmill.com.au>

* Update docs/pages/docs/apis/config.mdx

Co-authored-by: Tim Leslie <timl@thinkmill.com.au>

* Update .changeset/eight-lions-stare.md

Co-authored-by: Tim Leslie <timl@thinkmill.com.au>

Co-authored-by: Tim Leslie <timl@thinkmill.com.au>

.changeset/eight-lions-stare.md

@@ -0,0 +1,8 @@
+---
+'@keystone-next/keystone': major
+'@keystone-next/types': major
+---
+
+Replaced the `idField` list configuration option with a more constrained option, `db.idField`, that accepts an object with a `kind` property with a value of `cuid`, `uuid` or `autoincrement`. `db.idField` can be set on either the top level `config` object, or on individual lists.
+
+The default behaviour has changed from using `autoincrement` to using cuids. To keep the current behaviour, you should set `{ kind: 'autoincrement' }` at `db.idField` in your top level config.

.changeset/five-needles-deliver.md

@@ -0,0 +1,5 @@
+---
+'@keystone-next/keystone': major
+---
+
+Id field filters no longer allow `null` to be passed because ids can never be null. For the `in` and `not_in`, this is reflected in the GraphQL types