reorganize into app/ and server/

[cainlevy]

The new organization has three main divisions:

1. app/ contains domain logic
2. server/ maps the domain logic into a standard RESTful server using middleware and handlers
3. lib/ contains a few generalized things that haven't been fully extracted to standalone repositories

[cainlevy]

@mohammed90 Feedback would be appreciated in light of #83. I'm imagining that the gRPC logic would be a sibling of server/.

[mohammed90]

Okay, I'll take a look by next weekend. I'm currently down with flu.

[cainlevy]

Okay, no rush!

[mohammed90]

@cainlevy LGTM. I just have one thought:

In server/sessions/util.go, the getters explicitly rely on *http.Request. In gRPC side of work, I need exactly the same logic, but we don't have *http.Request there. So I copied those functions into the grpc package and adjusted funcs to take context.Context instead of *http.Request, which makes it agnostic to the source of the context.Context. Do you think it's better to refactor this logic to be reusable across both packages in this PR, or do you want to leave it for later when we're reconciling them?

The setter seems to have to be tied to the response type, so I can't think of a way to make it agnostic.

authn-server/server/sessions/util.go

Line 27 in f08fcf9

func Set(cfg *app.Config, w http.ResponseWriter, val string) {

[cainlevy]

@mohammed90 I'm back from the winter holiday and ready to finish up this refactor!

Do you think it's better to refactor this logic to be reusable across both packages in this PR, or do you want to leave it for later when we're reconciling them?

Let's see how it turns out in the end? The amount of duplication you're describing sounds acceptable to me.

[coveralls]

Coverage increased (+2.3%) to 77.197% when pulling ec4e796 on app-and-server into e57037c on master.