Test cases and small fixes

1. Added unit tests for analytics and some basic tests for the express server.
2.  The analytics example in `sample/basics` was based on Express 4.x. Changed it to make it runnable on 3.x
3.  If some records failed to get uploaded, add them to the queue to retry them. On `flush()`, the remote API responds back with the number of records it successfully pushed and the number that it failed. Add the number of failed ones back to the buffer. The records are processed sequentially so if 5 records are rejected, they will always be the last 5 ones.
     
Greg wanted to have a mechanism for flow control when an MP is overloaded where the client would back off progressively.  Another thing we might consider is writing messages to disk instead of dropping them, but after the conference we can prioritize the backlog and discuss what to tackle next.

--------------------------------------------------------------
Jeff West | Products | apigee | m: +1.214.450.9378 | twitter @jeffreyawest @apigee | Skype jeffrey.a.west
I ♥ APIs 2014 | September 8-10 | Fort Mason Center | San Francisco | #iloveapis | iloveapis2014.com

On Sep 8, 2014, at 10:41 PM, Dibyo Mukherjee <notifications@github.com> wrote:

> In analytics/apigee/lib/apigeeanalytics.js:
> 
> > @@ -64,9 +63,11 @@ ApigeeAnalyticsSpi.prototype.flush = function(recordsQueue, cb) {
> >        if (err || resp.statusCode != 200) {
> >          cb(err || new Error('error from server: ' + resp.statusCode), recordsToBeUploaded);
> >        } else {
> > -        cb();
> > +        resp.body.rejected > 0 ? cb(undefined, recordsQueue.slice(recordsQueue.length - resp.body.rejected))
> In most cases, all records should be accepted. However, if the analytics service is overloaded, it might reject a few records. The JIRA issue for this recommends the caller retry the rejected records, preferably using an exponential backoff algorithm.
> 
> —
> Reply to this email directly or view it on GitHub.
>