Add the nocgo build flag to enable a build without sqlite3

[silasdavis]

See description from commit below, but also:

• I prefer to keep my Go builds pure Go if possible (various reasons, some here: https://dave.cheney.net/2016/01/18/cgo-is-not-go)
• In particular static CGO (i.e. -extldflags 'static') are broken on Go 1.13 on archs I use
• This is motivated by library use, but you may have people who prefer vanilla-but-pure-go builds and this would enable that
• This is zero impact on your existing builds since db.go and blob_store.go are marked +build !nocgo. I suspect maintenance of the stubs will be non-onerous.
• I have used the build flag nocgo to build without needing sqlite3 which is your only CGO dependency, but I could use nosqlite3 or similar if you prefer. We kind of need the double negative because I don't want the normal builds to need a special flag, which we can achieve if the normal files are annotated with negated flag !nocgo
• If you are minded to accepted I can add a comment in readme somewhere noting how to use this and/or a makefile target.

---

This involves adding some stub files that panic if they are ever used on
a nocgo build - i.e. one excluding sqlite3 but the default build will
build with sqlite3 support using CGO.

CGO is great if you need it, but can cause various types of failures and
complexities particularly on on-standard toolcahins. As a library user I if I do not use sqlite3 I would rather not pay the prices of using CGO.

In particular at the time of writing static CGO builds with go 1.13 do
not work for me on musl-gcc or Arch Linux.

Signed-off-by: Silas Davis silas@monax.io

[coveralls]

Coverage remained the same at 77.44% when pulling 3462d0f on silasdavis:nocgo into 824d57d on keratin:master.

[silasdavis]

Pushing these aliases here just means we can isolate the CGO requiring files and wont' need another _nocgo.go file elsewhere

[mohammed90]

The double-negative tag of !nocgo is awkward. Wouldn't it be better to to switch around the logic to the tags cgo and !cgo?

Edit: never mind... Somehow the commentary on the double-negative didn't show for me when I wrote this comment.

[cainlevy]

if only there were another option for the kind of minimum effort getting-started experience that i like.

does it make sense for this to build another build target in the Makefile? that might be a natural place to document what's happening.

[cainlevy]

Suggested change

	panic("Cannot use sqlite3 BlobStore because building with nocgo build tag")
	panic("Cannot use sqlite3 BlobStore without cgo build")

[silasdavis]

I'll add a makefile target.

Would we prefer !nosqlite as a tag?

• more explicit about what support is being turned off (though perhaps less about why you would want to do that)

• if there is ever another cgo dependency we'll need another negated tag for that dep

[cainlevy]

i prefer nocgo. it describes the root cause, and does not create questions about nomysql, nopostgresql, and noredis.

[AlexCuse]

I think about this one sometimes when I think about ARM builds. Do we have any particular requirements for SQLite? There is eg https://pkg.go.dev/modernc.org/sqlite offering a pure go driver, it might not be as performant but our SQL usage is really simplistic it might be enough.

[cainlevy]

Sqlite is a good option for simple installs but is not necessary when Redis and either Postgres or MySQL are available.