scheduler WIP: add GetAllJobs api.

scheduler/api/scheduler/v1/scheduler.proto

 // Copyright 2016 The LUCI Authors. All rights reserved.
 // Use of this source code is governed under the Apache License, Version 2.0
 // that can be found in the LICENSE file.
 
 syntax = "proto3";
 
 package scheduler;
 
 
 // Scheduler exposes the public API of the Scheduler service.
 service Scheduler {
-  // TODO
+  // TODO: still in progress.
+
+  // GetJobs fetches all jobs satisfying JobsRequest and visibility ACLs.
+  rpc GetJobs(JobsRequest) returns (JobsReply);
 }
+
+message JobsRequest {
+  // If not specified or "", all projects' jobs are returned.
+  string project = 1;
+}
+
+message JobsReply {
+  repeated JobWithState jobs = 1;
+}
+
+message JobWithState {

[Vadim Sh., 2017/06/19 17:44:19]

just "Job"

if we need it without state, we can set state to nil (it is optional field)

[tandrii(chromium), 2017/06/20 11:48:05]

Done.

+  string id = 1;
+  string project = 2;
+  string schedule = 3;
+
+  JobState state = 4;
+}
+
+message JobState {
+  string kind = 1;

[Vadim Sh., 2017/06/19 17:44:19]

so... there are actually two flavors of state: one is used internally in state
machine, another is shown in UI. UI states are functions of internal state, they
are more user-friendly. See
https://github.com/luci/luci-go/blob/master/scheduler/appengine/ui/presentati...

I think we might need return UI-level state in API too, to avoid confusing
people. Internal state can be kept as internal implementation detail.

[tandrii(chromium), 2017/06/20 11:48:05]

I agree that UI one is more useful; however, if internal implementation detail,
then why expose it? So I don't expose it any more, and instead just offer usable
`string state` in it. WDYT?

[Vadim Sh., 2017/06/20 17:48:54]

Yes, I meant, the API should not expose internal job state. 

+}