Implement success criteria metrics for lesson checkpointing

[BenHenning]

Is your feature request related to a problem? Please describe.
Lesson checkpointing was implemented as a GSoC project last summer, but we didn't have time to implement the success criteria metrics expected for the feature here.

Describe the solution you'd like
The metrics should be implemented using the existing analytics framework. This feature should be documented at least in this issue with a high-level overview with the changes that need to be done in the code before actually starting implementation. A design document is not needed.

Describe alternatives you've considered
N/A

Additional context
None

[BenHenning]

@rishidyno this is actually a higher priority feature than #3825 and isn't blocked on UX (though it isn't a new UI). Might you be interested working on in this issue?

[theMr17]

Implementation

The metrics will be logged using the existing analytics framework. Each of the following events will be logged alongwith the ExplorationContext. As discussed with @adhiamboperes, here are the places where each of the event logs shall be triggered.

1. Progress saving success count
   This count will include the number of instances successful in saving user’s progress. The event will be triggered in ExplorationProgressController, the point where we receive a response that the checkpoint was successfully saved. Here.

2. Progress saving failure count
   This count will include the number of instances failed in saving user’s progress. The event will be triggered in ExplorationProgressController, the point where we receive a response that the checkpoint has failed to save. Here.

3. Lessons saved advertently count
   This count will include the number of instances user exits the exploration advertently, i.e., by using the 'X' icon or the back button. The event will be triggered in ExplorationActivityPresenter, inside backButtonPressed function. Here.

4. Lessons saved inadvertently count
   It will be preferred to calculate the metric as shown below, because logging the event will be a bit complex in this situation. This metric includes scenarios of app crashes, updates, topic deletions and reinstalls, so separating them from total saving attempts will be difficult.

   Lessons saved inadvertently count = Total saving attempts count - Lessons saved advertently count

5. Total saving attempt count

   Total saving attempt count = Progress saving success count + Progress saving failure count

6. Start over count
   Already implemented as a part of Learner Analytics. Here.

7. Continuation count
   Already implemented as a part of Learner Analytics. Here.

8. Correct answer count after returning to the lesson
   A new variable will be introduced in ExplorationProgressController.ControllerState to log the event only when a resumed lesson is played. The event will be triggered in ExplorationProgressController, inside ControllerState.submitAnswerImpl function. Here.

9. Incorrect answer count after returning to the lesson
   This count will be same as above but will be logged in case of incorrect answer submission.

File Changes

The following tables list the files that will be modified in each of the modules.

App module

File	Change
ExplorationActivityPresenter.kt	Log lessons saved advertently.

Domain module

File	Change
ExplorationProgressController.kt	Log progress save success & failure, correct & incorrect answer.
LearnerAnalyticsLogger.kt	Log the events via AnalyticsController.

Model module

File	Change
oppia_logger.proto	Introduce context fields for above events.

Utility module

File	Change
EventBundleCreator.kt	Convert new fields to ActivityContext.
StandardEventTypeToHumanReadableNameConverterImpl.kt	Add human readable names for above events.
KenyaAlphaEventTypeToHumanReadableNameConverterImpl.kt	Add human readable names for above events.