Manually removing an orphaned entity type I have been handed an older Drupal 8 site and asked to update it to run with composer. I didn't do it in the cleanest possible way but it is working. I have run into trouble updating it.
I am most of the way there. Have rebuilt it and it is now managed with composer. However, In trying to run the final DB updates I am stuck with the following error blocking update:
[notice] Update started: system_post_update_entity_reference_autocomplete_match_limit
[error]  The &quot;support_ticket&quot; entity type does not exist. 
[error]  Update failed: system_post_update_entity_reference_autocomplete_match_limit 
[error]  Update aborted by: system_post_update_entity_reference_autocomplete_match_limit 
[error]  Finished performing updates. 

The &quot;support_ticket&quot; module was on the old site and in the DB but not enabled. I have tried adding and removing it and the &quot;support&quot; module that is its parent but the above error remains.
Is there a way for me to manually stop the system updating that entity type? Or inserting a placeholder? Or some other solution that lets me update the site.
MORE INFORMATION
The module Support and it's sub-module support ticket don't even appeat to be current drupal 8 projects. The last contribution to their d8-port github page is from 2015.
After some messing around I realise the sub-module support_ticket does not only fail to uninstall but it can't be re-installed either. If you try to re-install it you get the following error:
Unable to install Support ticket, comment.type.support_ticket_update, 
core.entity_form_display.comment.support_ticket_update.default, 
core.entity_form_display.support_ticket.ticket.default, 
core.entity_view_display.comment.support_ticket_update.default, 
core.entity_view_display.support_ticket.ticket.default, 
field.field.comment.support_ticket_update.comment_body, 
field.field.comment.support_ticket_update.field_revision_changes, 
field.field.comment.support_ticket_update.field_revision_reference, 
field.field.support_ticket.ticket.body, 
field.field.support_ticket.ticket.field_assigned_to, 
field.field.support_ticket.ticket.field_priority, 
field.field.support_ticket.ticket.field_related, 
field.field.support_ticket.ticket.field_state, 
field.field.support_ticket.ticket.field_ticket_update, 
field.field.support_ticket.ticket.field_watchers, 
field.storage.comment.field_revision_changes, 
field.storage.comment.field_revision_reference, 
field.storage.support_ticket.body, 
field.storage.support_ticket.field_assigned_to, 
field.storage.support_ticket.field_priority, 
field.storage.support_ticket.field_related, 
field.storage.support_ticket.field_state, 
field.storage.support_ticket.field_ticket_update, 
field.storage.support_ticket.field_watchers, 
filter.format.support_ticket_diff, support_ticket.settings, 
support_ticket.type.ticket, system.action.support_ticket_delete_action, 
system.action.support_ticket_lock_action, 
system.action.support_ticket_publish_action, 
system.action.support_ticket_save_action, 
system.action.support_ticket_unlock_action, 
system.action.support_ticket_unpublish_action, 
views.view.support_ticket_overview, views.view.users_support_tickets 
already exist in active configuration.

I am guessing at this point I would need to manually delete entries from the DB?
In case it is of use to anyone else dealing with an old module that doesn't uninstall correctly. The solution to my problem was the following.
WARNING: Do this on a copy of your actual site and database. You could break a live site doing this.
Most of the troublesome database entries are in the config table.
You can use the error list produced above when trying to install the module to track down the rows to purge.
In the database a query such as:
SELECT name FROM config WHERE name LIKE '%support_ticket%';
should show you most of the problematic entries.
In my case that exactly matched the offending active configuration so i could just change the above to:
DELETE FROM config WHERE name LIKE '%support_ticket%';
I would be very careful about doing this with a LIKE query unless you are sure you won't accidentally delete something else.
I assume directly removing entries like this in the database is probably a bad idea but I really couldn't find another way to move forward.
Once the above is done Drush updb worked and the update completed.