1️⃣ Autonumber: Add field type

What is in this MR

The new autonumber field type. This new field type numbers all the rows according to the current view filters and sorts. It also numbers rows that are not visible (if any) in the current view, using the default table ordering (by order and id). Once the field is created, the row numbers will not change updating the field, but only when a field is created or a different field type is converted to this new autonumber type.

How to test this MR

• An autonumber field can be created. Once created, all the rows will be numbered according to the current filters and sorts. All remaining rows will also be numbered with higher numbers. If new rows are inserted, the row value will be the following available numbers in the sequence.
• An autonumber field can be updated. The user can only update the field name. The row numbers will not change once set.
• An autonumber field can be deleted. If the user adds new rows while the field is trashed and then restores the field, the new rows will automatically have a valid number because the database sequence is not dropped while the field is trashed.
• When an autonumber field is permanently deleted or is updated to a different field type, the db sequence is dropped.
• Read only field, can't be updated manually
• When a different field_type is converted to the autonumber type, all the rows are numbered accordingly to the view and a new db sequence is created and used for new rows.
• An autonumber field can be duplicated. The data will be duplicated and a new db field sequence will be created for the new field.
• A table/database with one or more autonumber fields can be duplicated. The new fields will have proper db sequences for new rows.
• Values of an autonumber field can be exported/imported.
• The new field values are correctly shown as numbers in the grid, gallery, kanban and calendar view types.
• The field can't be used in form views.
• In this MR, the autonumber field cannot be used in filters and sorts. It doesn't have aggregations and it cannot be referenced in formulas.
• APIDocs are correct
• Redoc is correct
• Our commands for data generation still work: (fill_table_fields, fill_table_rows, fill_row_history)
• It's possible to export/import workspaces with autonumber fields from the CLI (export_workspace_applications/import_workspace_applications)
• if you stop the dev server and run BASEROW_BACKEND_DEBUG=off DJANGO_SETTINGS_MODULE=baserow.config.settings.base ./docker/docker-entrypoint.sh gunicorn-wsgi creating a new field should take about 10s for a table with 100k rows.
• Verify that test_field_conversion_autonumber can convert to and from other field types with: pytest --run-disabled-in-ci -s -c pytest.ini tests/ -k test_field_conversion_autonumber

Not addressed in this MR:

• what should we do with table with 500k rows or more? At the moment, creating an autonumber field in a similar table would take 1 minute or more, and the request will probably fail due to the gunicorn worker timeout.

Merge Request Checklist

• changelog.md has been updated if required.
• New/updated Premium/Enterprise features are separated correctly in the premium or enterprise folder
• The latest Chrome and Firefox have been used to test any new frontend features
• Documentation has been updated
• Quality Standards are met
• Performance: tables are still fast with 100k+ rows, 100+ field tables
• The redoc API pages have been updated for any REST API changes
• Our custom API docs are updated for changes to endpoints accessed via api tokens
• The UI/UX has been updated following UI Style Guide

Closes #811 (closed)