Make job execution limits flexible.

1. Change the execution timeout to allow all jobs to run for longer than
   10 minutes if the app has sufficient quota and JobScheduler is quiet.
   If jobs end up running longer than 10 minutes, their execution is
   capped at 30 minutes or their remaining quota, whichever is less.
   Overrunning jobs will also be stopped if there are pending jobs
   waiting for an execution slot.
2. Expedited jobs will have a minimum execution timeout of 3 minutes.
   The above behavior with flexible limits also apply to EJs. However,
   EJs will not be allowed to overrun if the device is in Doze or
   battery saver. The limit is flexible, but EJs for apps in the
   RESTRICTED bucket cannot have a minimum timeout greater than 5
   minutes (ie. if we change the minimum timeout for EJs to be greater
   than 5 minutes, RESTRICTED EJs will have their minimum set to 5
   minutes).
   Since TOP-started jobs and jobs running while the app is FGS don't
   count towards quota, their calculations are handled separately. Those
   jobs currently have a minimum guarantee of 15 minutes (50% of
   ACTIVE/WORKING limits = 15 minutes). The gist of the allowance is:
      min runtime = 5 minutes
      TOP: max(min runtime, 50% ACTIVE limit, remaining quota)
      FGS: max(min runtime, 50% WORKING limit, remaining quota)
      Else: max(min runtime, remaining quota)
3. Update documentation to clarify execution limit differences across
   versions.

Bug: 19536175
Bug: 171305774
Test: atest CtsJobSchedulerTestCases
Test: atest FrameworksMockingServicesTests:ConnectivityControllerTest
Test: atest FrameworksMockingServicesTests:JobSchedulerServiceTest
Test: atest FrameworksMockingServicesTests:QuotaControllerTest
Test: atest FrameworksServicesTests:PrioritySchedulingTest
Test: atest FrameworksServicesTests:WorkCountTrackerTest
Test: atest FrameworksServicesTests:WorkTypeConfigTest
Change-Id: I21674fdcddfa849581198a1a9133c431fb7cfa46