... in the event that a timer is created during a topology event.

Currently, distributed timers use a Scheduler<UUID, TimerMetaData> wrapped with a PrimaryOwnerScheduler decorator.

If a scheduling operation following timer creation is directed to a remote cluster member (this can happen if the topology changes after the timer ID is created, but before the timer is scheduled) due to the transactional nature of the cache, we need to send the metadata along with the timer ID, however, the TimerMetaData is not marshallable.  To fix, create a sub-interface with a marshallable implementation, e.g. like we do for ExpirationMetaData (for distributed HttpSessions/SFSBs).

This is somewhat rare currently, but following WFLY-19550 will happen for any timers created during PostConstruct on a server starting in suspended mode.