* previous `schedule` method is trying to maintain a fixed average frequency
over time, but that can result in undesired bursts of scheduled tasks after a long
GC or if the JVM process has been suspended, same with all other periodic
scheduled message sending via various Timer APIs
* most of the time "fixed delay" is more desirable
* we can't just change because it's too big behavioral change and some might
depend on previous behavior
* deprecate the old `schedule` and introduce new `scheduleWithFixedDelay`
and `scheduleAtFixedRate`, when fixing the deprecation warning users should
make a concious decision of which behavior to use (scheduleWithFixedDelay in
most cases)
* Streams
* SchedulerSpec
* test both fixed delay and fixed rate
* TimerSpec
* FSM and PersistentFSM
* mima
* runnable as second parameter list, also in typed.Scheduler
* IllegalStateException vs SchedulerException
* deprecated annotations
* api and reference docs, all places
* migration guide
* ⇒, →, ←
* because we don't want to show them in documentation snippets and
then it's complicated to avoid that when snippets are
located in src/test/scala in individual modules
* dont replace object `→` in FSM.scala and PersistentFSM.scala
* Add CopyrightHeader support for sbt-boilerplate plugin.
* Add CopyrightHeader support for `*.proto` files.
* Add regex match for both `–` and `-` for CopyrightHeader.
* Add CopyrightHeader support for sbt build files.
* Update copyright from 2018 to 2019.
AutoReceivedMessage with FSM schedule bug fixed (#24080)
Tests added for both FSM and Timers trait for (#24080)
AutoReceivedMessage with PersistentFSM bug fixed and test added (#24080)
* Apply [Boy scout rule](https://github.com/akka/akka/blob/master/CONTRIBUTING.md#additional-guidelines)
* [Bug#23329] PersistentFSM: andThen callbacks are not executed when stay()
* [fixes#23329] PersistentFSM: andThen callbacks go execute when stay()
* At documentation: there is nothing said about events applied should decide to invoke andThen or not.
* At code: andThen callback can be specified whether any events/state transition applied or not.
Added call to nextState.afterTransitionDo(stateData) even if there are no eventsToPersist
`State.using` is a valid pattern in regular FSM. However, for persistent FSM
it makes no sense and is marked as `private[akka]`. The `private[akka]` modifier does
not translate into bytecode so that Java users won't see that it should not be used.
Deprecating it will allow us to remove it in the future.
Fixes#23739.
* backport of the timers from Akka Typed, #16742
* also fixed a small bug in FSM timers, which could result in that
a timer from a previous incarnation was let through to new
incarnation after restart
* no more need for the complicated "how to" section in docs of
how to schedule periodic messages
* Use snapshot-after in config to periodical snapshot in PersistentFSM (#21563)
* akka.persistence.fsm.snapshot-after is either off or a numerical value
* Use Akka Extension for snapshot-after in PersistentFSM
* marked PersistentFSM as experimental
* also changed the order of some sections in migration guide
* link to 2.2->2.3 migration guide
* update experimental index page
