Set a lock_wait_timeout on the MySQL connection

[SuperQ]

Set a session level lock_wait_timeout to avoid stuck metadata locks.

Closes: #167

[SuperQ]

/cc @rtreffer

[AlekSi]

[arvenil]

I'm surprised if this really works because you can't guarantee that db.Query() will be executed on the same session. Considering that this exporter limits number of open sessions, there is a chance it actually works... but this is still not guaranteed.

db is a session pool, and even with db.SetMaxOpenConns(1) you don't have guarantee that next db.Query() will use the same session as previous db.Query() call. It could always got close in background and new session could get open.

The only way to ensure you are using the same session is to use transactions.

go-sql-driver/mysql#208

[SuperQ]

db objects are created per scrape, it's not global for the exporter. But, as was pointed out in another PR, there are better ways to deal with this via the DSN string. I will probably refactor this later for better control.

[arvenil]

@SuperQ just to clarify my position. Yes, you are right db is per scrape, but during scrape we are running multiple queries, and each query is picking a connection from connection pool. Yes, the connection pool is limited to just one connection, but this only means it's one connection at a time, not the same connection always.
For example here
https://golang.org/src/database/sql/sql.go?s=34389:34668#L1267
you can see we try to get connection few times, and if you dig deeper you will see it tries to grab cached one or if it doesn't work then it will create new one.

I just noticed new func, looks like recently added, and doc for this func explicitly says "Queries run on the same Conn will be run in the same database session. "
https://golang.org/pkg/database/sql/#DB.Conn
golang/go@d234f9a
Never used that, so can't say how well it works, but could be an option for you.
(well, I don't agree with this 1-connection pool so maybe I shouldn't suggest it ;))