Investigate encoding issue in soci/postgresql

[MonsieurNicolas]

It looks like we're missing setting the proper encoding when we're talking to the database:

• forcing the database to be created with utf8 encoding showed that we can have SQL errors
• such an example was fixed by filtering data that could yield bad SQL

Ideally the default encoding of the database should not matter: we should create tables and queries with "C" encoding (and not rely on utf8 decoder on the sql side which probably has some performance impact).

[graydon]

@MonsieurNicolas I'm a little unclear on the errors we can have, or what the problem here is. Can you elaborate?

[MonsieurNicolas]

Ah yes, this was something that could only be triggered from test cases and with postgres setup with utf8 as encoding (in travis we don't create temp databases):
basically we used to not have the check https://github.com/stellar/stellar-core/blob/master/src/ledger/LedgerTxnTrustLineSQL.cpp#L25 and we could call LedgerTxnRoot::Impl::loadTrustLine(LedgerKey const& key) const with a garbage asset (must contain an invalid utf8 byte sequence) like what we can do in https://github.com/stellar/stellar-core/blob/master/src/ledger/test/LedgerTxnTests.cpp#L1426

What would happen then is that we'd get a "invalid utf-8 sequence" error from postgres -> soci -> abort.