Convert the entity_legal_document_version entity ID from string to serial

We are creating entities programmatically and we hit "When there are two different legal document versions created at the same second." case.
Maybe better replace that to "return $entity->bundle() . '_' . microtime(TRUE);"? Still far from perfection but slightly less likely we will get a fatal error.

Why not fixing it once for ever? I mean to move to serial. But the update path will not be easy (probably)

Anyway, there's no 4.0.x stable release yet. So, maybe, we afford to break backwards compatibility. Still need to check whether 4.0.x is aligned with 3.0.x

Switching back to task

Few notes for reviewer:

• This conversion is extremely complex. I couldn't fined any documentation or example on how to change the entity ID type (in this case from string to serial).
• After several tries to use the entity definition update service, I've gave up and chose to do direct queries against the database.
• There are no tests. I tried to add but it was overkill and overwhelming. This should be tested manually (tagged as so)
• There's also an update path for views using the changed fields. However, I acknowledge that might not cover the whole situations out in the wild. At least, it covers the view provide by the module but also other views. For sure not all views that can be imagined based on the entities provided by this module. But such views are quite easy to be fixed from the UI by site builders, if case.
• We're doing this change in 4.0.x, which is a module's new major version. That means any disruption is acceptable, including not having a 100% update path. Projects are responsible to adapt, even to provide additional update paths if they need.

alorenc → closed merge request !13

Republishing reviewer notes:

• This conversion is extremely complex. I couldn't find any documentation or example on how to change the entity ID type (in this case from string to serial).
• After several tries to use the entity definition update service, I've gave up and chose to do direct queries against the database. Still used the entity definition update service where it was possible.
• Added update path test coverage. However, this should be tested also manually (tagged as so).
• There's also an update path for views using the changed fields. I acknowledge that it might not cover the whole situations out in the wild. At least, it covers the view provided by the module but also other views. For sure not all views that can be imagined based on the entities from this module. But such views are quite easy to be fixed from the UI by site builders, if case.
• We're doing this change in 4.0.x, which is a module's new major version. That means any disruption is acceptable, including not having a 100% update path. Projects are responsible to adapt, even to provide additional update paths if they need.
• Initially I've encountered an edge case failure, which is documented in entity_legal_update_last_removed(). I know, my workaround doesn't look so goods but it's efective. If you want to see the failure just move the code from entity_legal_update_last_removed() (the lines inside if (...)) into entity_legal_update_9002().
• The update path has been tested with MySQL and PostgreSQL. If there are projects with other DB drivers we're more than happy to accept patches that are improving the update path.

Adding https://www.drupal.org/project/entity_legal/issues/3358135 🐛 Missing query access check WSOD Closed: duplicate as a related issue only because that issue is more specific to something that was already fixed in the current one without being in the scope.

+1RTBC here :)

Crediting @idimopoulos for review.

Automatically closed - issue fixed for 2 weeks with no activity.