SAMZA-1880: Rename non-metrics classes which use Timer in their name

[cameronlee314]

Summary of API changes:

1. TimerRegistry -> KeyScheduler; register -> schedule
2. TimerFunction -> SchedulingFunction; registerTimer -> schedulingInit, onTimer -> executeForKey
3. TimerCallback -> SchedulingCallback onTimer -> execute
4. TaskContext: registerTimer -> scheduleCallback, deleteTimer -> deleteScheduledCallback

Only terminology changes are intended (e.g. classes, var names, logs). No functionality change is intended.
An upcoming PR will further update TaskContext and the access to the scheduling logic.

[cameronlee314]

@xinyuiscool @prateekm can you please take a look?

[prateekm]

@cameronlee314 Just looking at the names in the description, I'd prefer to not use key in the names since it's an overloaded term. How about something along these lines:

1. TimerRegistry -> Scheduler; register -> schedule
2. TimerFunction -> ScheduledFunction; registerTimer -> schedule, onTimer -> onCallback
3. TimerCallback -> ScheduledCallback onTimer -> onCallback
4. TaskContext: registerTimer -> scheduleCallback, deleteTimer -> deleteScheduledCallback

This way we're only introducing 2 new terms - schedule and callback, and both are fairly familiar concepts.

[cameronlee314]

Thanks for the suggestion @prateekm. I wasn't too fond of KeyScheduler either. The reason I did use that name was that when we consolidate TaskContext.scheduleCallback and TaskContext.deleteScheduledCallback into a TaskContext.something, I was thinking of using "Scheduler" for that. Now, I'm thinking that I could use something like SchedulerCallbackRegistry for that TaskContext case.

[cameronlee314]

@xinyuiscool @prateekm could you please take another look at this?

[prateekm]

Looks great, thanks for cleaning this up. Some documentation related suggestions.

[cameronlee314]

Thanks for the doc suggestions. I like them much better than what I came up with.

[cameronlee314]

@prateekm @xinyuiscool could you please take another look?

[prateekm]

Thanks!