admin: Add account endpoint.

[JoeGruffins]

Part of #329

[JoeGruffins]

Whoops:
failed to retrieve accounts: sql: Scan error on column index 3, name "fee_coin": unsupported Scan, storing driver.Value type <nil> into type *dex.Bytes
I suppose it is because sql doesn't work well with custom types? Have removed all custom types from the Scan just in case.

[chappjc]

Custom types need either (1) built-in underlying type, or (2) define Scan and Value methods to satisfy sql.Scanner and sql.Valuer interfaces. We have those define for many types. I suggest looking at those for examples. e.g. for AccountID:

dcrdex/server/account/account.go

Lines 41 to 59 in 95d8c3f

	// Value implements the sql/driver.Valuer interface.
	func (aid AccountID) Value() (driver.Value, error) {
	return aid[:], nil // []byte
	}
	// Scan implements the sql.Scanner interface.
	func (aid *AccountID) Scan(src interface{}) error {
	switch src := src.(type) {
	case []byte:
	copy(aid[:], src)
	return nil
	//case string:
	// case nil:
	// *oid = nil
	// return nil
	}
	return fmt.Errorf("cannot convert %T to AccountID", src)
	}

, which does the copy that you are doing manually now.

However, the error here indicates that dex.Bytes, which is just []byte doesn't handle NULL values in the table. Note that the NULL issue is so common that there are standard types like sql.NullString and sql.NullInt64 for this reason. For byte slices, I think it should just work with NULLs. How do you get this error (what code and test)?

[chappjc]

I can repro the error by changing getAccount to use dex.Bytes instead of []byte. I'm OK with Scanning into a []byte and just converting like you have. But we can definitely scan into an account.AccountID directly because we have implemented sql.Scanner for that and it's the primary key that can never be null.

Also broken_rule has a non-NULL default, so that's OK to scan directly into an account.Rule too I believe.

As for FeeAddress, we'll probably want to scan into a sql.NullString to be safe.

[JoeGruffins]

Adding a Scan method to dex.Bytes looks to has solved the problem. Is this alright? It seems odd that this is needed since scanning when the value is not null used the underlying type's Scan.

[chappjc]

It is odd, but we had to do something like this with the Preimage scanner I believe.

[chappjc]

Let's also test Accounts and AccountInfo before PayAccount to test the null cases.

[JoeGruffins]

I added a separate nullifying section.

[chappjc]

There's a brutal gotcha here. You actually need to create a new bytes slice and copy the bytes because the sql driver reuses src and the underlying buffer changes all the data you already scanned in.

[JoeGruffins]

Thank you. That saves a bunch of headaches down the road.

[chappjc]

I'm good with these tests, although note that that the account id is the hash of the pubkey, so they will both be set always unless the DB is corrupted. Still the db scheme doesn't prevent pubkey from being null so I think this is a good test.

[chappjc]

For posterity's sake, the results, which could be augmented with an individual account's active swaps at some point:

$   dexadm accounts
[
    {
        "accountid": "93e6566e0c4c5c3ac03514fe532f494a7a71b392031c462087bb8c511d532149",
        "pubkey": "0282c421175228136a9f9ed42e7fa63ce4f33900eca27ea1d4675c56e8675b01bf",
        "feeaddress": "SsonWQK6xkLSYm7VttCddHWkWWhETFMdR4Y",
        "feecoin": "f680451275ce09feecb9cc21d829e6e5eeb966dc2c57360f91696ac80742e88a00000000",
        "brokenrule": 0
    }
]

 $   dexadm account/93e6566e0c4c5c3ac03514fe532f494a7a71b392031c462087bb8c511d532149
{
    "accountid": "93e6566e0c4c5c3ac03514fe532f494a7a71b392031c462087bb8c511d532149",
    "pubkey": "0282c421175228136a9f9ed42e7fa63ce4f33900eca27ea1d4675c56e8675b01bf",
    "feeaddress": "SsonWQK6xkLSYm7VttCddHWkWWhETFMdR4Y",
    "feecoin": "f680451275ce09feecb9cc21d829e6e5eeb966dc2c57360f91696ac80742e88a00000000",
    "brokenrule": 0
}