check if go version is 1.2 or above

Check if the go version is above 1.2, instead of matching hard against
1.2. Since 1.3 is released and the tests seem to pass I think it should
be possible to build with 1.3 as well. This is needed to build with
homebrew as well since go 1.3 is the default version there, see
https://github.com/Homebrew/homebrew/pull/29736

Fixes #343
potential fix for issue #335
fix test for issue #335

Updated sync function role based tests to pass a Map with role names as keys, rather than an array of role names
Merge pull request #347 from sideshowcoder/build-with-go-above-1.2

check if go version is >= 1.2 (not ==1.2)
Fixed broken go.sh from previous commit.

Apparently sideshowcoder has a different version of awk installed, that
supports different syntax from the default version in OS X 10.9.
Fix go version number extraction

We really need to check to major.minor so 1.2.1 should be considered
1.2. while 1.32 should be considered 1.32 even though their aren't
double digit minor versions today I think it makes sense to consider
them.

This has been tested against the version strings

go version go1.3 darwin/amd64
go version go1.2.1 darwin/amd64
go version go1.2 darwin/amd64
go version go1.31 darwin/amd64
Merge pull request #350 from sideshowcoder/fix-version-number-match

Fix go version number extraction
Refactoring: Move rest.updatePrincipal to db package

Updating users is going to involve some extra work (allocating a
sequence) so I'm moving it downwards into the innards of db.
For #314
Users/roles now have sequence numbers that update when they change.

This avoids problems with the _changes feed after a user is given access
to a channel.
Fixes #314
Merge pull request #348 from couchbase/feature/issue_335

Fix requireRole() function

Fixes #335
Fix for issue #332
Now Open shadow bucket with full server URL including user credentials if present, this allows password protected buckets to be opened.
Fix infinite loops in changes feed by reordering new channels' items

When a user gets access to a channel at sequence m, the pre-existing
items in that channel now appear in the feed right before sequence m,
with sequence IDs of the form "m:n" where n is the actual sequence # of
the item. This allows the changes feed to pick up where it left off,
avoiding infinite loops.
It does mean that public sequence IDs can now be strings, not just
numbers. But clients should not mind, since the IDs are opaque to them.
Fixes #314 (again!)
fixes issue #335
A patch to extend a cookie based session, when a user accesses sync gateway after 10% of the session expiration has elapsed, the original session ttl is added to the current system time and the session and cookie are updated and new cookie is returned to the client.

A new test has been added to the admin api
Fixed incorrect HTTP+ logging of all request times as "0.0 ms"

Dumb typo, not helped by the goddamn Go compiler's insistence on not
warning about shadowing local variables. :-p
Merge pull request #364 from couchbase/feature/issue_314

Fix infinite loops in changes feed by reordering new channels' items
Improved readability of cookie expiration tetsts
minor formatting fix
Properly invalidate users/roles when doc is deleted

A deleted doc doesn't grant access to any channels or roles. But deleting
a doc didn't invalidate the affected users/roles' caches, so they
wouldn't always update correctly. Fixed this by having the deletion
always set the doc's channel/role access to empty sets.

This doesn't actually fix #337, but it reduces it to the already known
issue that losing access to a channel doesn't causing its docs to be
revoked in the changes feed (#264).
Facebook is not guaranteed to return an email address from a call to /me.  I've added a check to rest.makeSessionFromEmail which will return a descriptive error in this case.
Update session.ttl to store string formatted duration