Refactor Middleware

[dansackett]

With access logs now pulled into the source tree, we should work on refactoring the middleware implementation as outlined in #46 (this comment).

Things to do include:

• Create a new directory in the root called middleware. This will exist as a subsequent package for use with our conduit.
• Add Alice as a means for chaining middleware and keeping our main file clean.

[dansackett]

@scottcrespo when I was working on this tonight, I realized that setting up middleware in another package may have weird affects. I haven't thought much about this past the initial error but it's something to consider: we may have circular imports here.

With the logging, we call parts of the Config struct to get the load balancer and other attributes. So in the logging package I need to import the conduit directory in order to get access to these things. And in the conduit main.go file I need to import the middleware finishing the circular dependency.

In the case of the Config struct there isn't really a way around this because it's a custom data type and passing it to a function would still require the definition.

Maybe I'm not thinking properly but I think we have to rethink this idea into something more manageable. This could potentially include refactoring logging out out of the conduit and building a new package that allows dynamic attributes to be logged. Either way, just wanted to hear thoughts.

[scottcrespo]

@dansackett

Ya, I think I ran into a similar issue when creating the config.go module. There may be a larger refactoring requirement needed so that we can have more packages than just main

So maybe we should pare down the requirement here so that we include middleware chaining capabilities, but break off another ticket for refactoring eps-conduit into multiple packages.