Initialize TaskScheduler in remoting processes.

remoting/client/jni/chromoting_jni_runtime.cc

Index: remoting/client/jni/chromoting_jni_runtime.cc
diff --git a/remoting/client/jni/chromoting_jni_runtime.cc b/remoting/client/jni/chromoting_jni_runtime.cc
index 1505e441aeba54c9e7dfe49bb957f38b6af6b0dc..231038560c7771096e05e4992a8408a3ac1e0873 100644
--- a/remoting/client/jni/chromoting_jni_runtime.cc
+++ b/remoting/client/jni/chromoting_jni_runtime.cc
@@ -14,6 +14,7 @@
 #include "base/memory/singleton.h"
 #include "base/stl_util.h"
 #include "base/synchronization/waitable_event.h"
+#include "base/task_scheduler/task_scheduler.h"
 #include "jni/JniInterface_jni.h"
 #include "remoting/base/chromium_url_request.h"
 #include "remoting/base/url_request_context_getter.h"
@@ -42,6 +43,9 @@ bool RegisterChromotingJniRuntime(JNIEnv* env) {
 static void LoadNative(JNIEnv* env, const JavaParamRef<jclass>& clazz) {
   base::CommandLine::Init(0, nullptr);
 
+  const int kMaxBackgroundThreads = 5;

[joedow, 2017/02/01 23:20:42]

I see that 5 is used consistently in this CL, is there anything special about
this value?  If so, then a comment would be good.

[Sergey Ulanov, 2017/02/02 00:14:19]

No, there is nothing scientific about this value. It could be 2 or 20, and that
would make no difference in practice. 
FWIW chrome scales number of background threads proportional to number of CPUs.
I don't think it's necessary for chromoting right now, as number of places where
TaskScheduler is used is very limited. Note that chrome also separate different
classes of threads in different pools.
I've added a TODO in each of these 5 places to reconsider the policies,
particularly when TaskScheduler becomes more widely used.

Potentially we could redo threading logic for the host, e.g. it could use
TaskScheduler for the encoder. That would require configuring TaskScheduler to
use separate pool for these tasks.

+  base::TaskScheduler::CreateAndSetSimpleTaskScheduler(kMaxBackgroundThreads);
+
   // Create the singleton now so that the Chromoting threads will be set up.
   remoting::ChromotingJniRuntime::GetInstance();
 }