Fire events when starting and ending session access.

Originally by @Legioth

Frameworks like JPA are often used with a transaction-per-request pattern where a new transaction is started at the beginning of every request and then committed or rolled back the request after the request has been handled.

In Vaadin 6, this was usually implemented using TransactionListener or HttpServletRequestListener. Vaadin 7 removed support for those features and it was instead recommend to use a servlet filter (see e.g. #10983). The introduction of server push and UI.access(Runnable) in Vaadin 7.1 furthermore means that the same HTTP request might (asynchronously) touch multiple sessions that should probably each have their own transaction. The push support also encourages patterns where a session is accessed outside the context of a HTTP request, e.g. from a custom worker thread.

All in all, it seems that the concept of transaction-per-request can no longer work sensibly with Vaadin applications. Transactions should instead be bound to session access; starting a transaction when locking the UI and ending the transaction when unlocking.

To support this, events should be fired whenever VaadinSession is locked or unlocked. Some thoughts about the implementation:

• Unlocking events should be fired in the opposite order of locking events.
• The event could include information on why the access was initiated, e.g. request initiated by the client, heartbeat handling or access() from an unrelated request or a custom thread.
• Events should only be triggered when using one of the access methods - manually retrieving the lock instance and directly operating on it should not fire any events.
• access() for the same session during a lock event would queue the Runnable to be run after all listeners have been notified.
• access() for the same session during an unlock event would schedule a new access (firing new lock and unlock events) after all listeners have been notified. The lock is released between the two accesses to give other accessors a chance.
• Data that might be useful in the unlocking event:

• Which UIs have been marked as dirty during the access
• For which UIs a response or push message has been produced
• Did the access end normally or was there an uncaught exception?

Imported from https://dev.vaadin.com/ issue #12256

Start with VaadinSession's access methods and the locking and unlocking flow described in the issue; no specific files or tests are named. Define the event lifecycle and access-context data, including listener ordering and normal versus exceptional completion, then verify that only supported access methods fire events and that nested access is queued or rescheduled as specified.