Dead lock in deactivating a processing engine trigger.

[jacksonrnewhouse]

Steps to reproduce:
List the minimal actions needed to reproduce the behaviour.

1. Create a trigger that writes data back to the database.
2. Deactivate it while it is doing other work. If you write data back on an all_tables trigger this will mean it is continuously writing data after any initial write, which is an easy way to trigger it.
3. Deactivate the plugin.

Expected behaviour:
The plugin should be deactivated by the next WAL flush, returning successfully to the CLI call.
Actual behaviour:

• The plugin host code calls write_lp() to write data back to the DB. This blocks until the wal file is flushed.
• The deactivate call take the plugin_event_tx lock in order to send the shutdown message. This lock is held until it gets a response back.
• When the WAL flushes it attempts to send the new WAL data to plugins via notify, but can't take the lock. The Shutdown message is yet to be processed as it is behind the earlier WalContents.

Fix should be straightforward, don't hold the lock while waiting for the shutdown response.