implement getConfiguration on `UserMapper`

[zarvox]

LiskDAO objects are expected to describe their expected schema, and rules on said schema.

UserMapper probably ought to specify at least a self::CONFIG_COLUMN_SCHEMA and a self::CONFIG_KEY_SCHEMA so Phabricator won't complain about the unregistered columns:

Database                 Table                    Name              Issues
phabricator_calendar     calendar_event           userPHID_dateFrom Surplus Key
phabricator_calendar     calendar_event           key_date          Missing Key
phabricator_file         file_transaction_comment key_draft         Surplus Key
phabricator_harbormaster harbormaster_build       key_initiator     Missing Key
phabricator_herald       herald_rule              name              Better Collation Available
phabricator_herald       herald_rule              key_name          Missing Key
phabricator_packages     packages_package         name              Better Collation Available
phabricator_packages     packages_publisher       name              Better Collation Available
phabricator_search       search_document          key_type          Missing Key
phabricator_user         user_mapper              id                Wrong Column Type
phabricator_user         user_mapper              ss_id             Surplus Key
phabricator_worker       worker_archivetask       key_modified      Missing Key
Applying schema adjustments...
Completed applying all schema adjustments.

Target                                           Error
phabricator_user.user_mapper.ss_id               Column Has No Specification
phabricator_user.user_mapper.phabricator_user_id Column Has No Specification

 SCHEMATA ERRORS 

The schemata have errors (detailed above) which the adjustment workflow can
not fix.

If you are not developing Phabricator itself, report this issue to the
upstream.

If you are developing Phabricator, these errors usually indicate that your
schema specifications do not agree with the schemata your code actually
builds.

My glance over some schemas suggests that the user mapper migration should also make a few changes to be consistent with the other schemas:

• phabricator_user_id should be a varbinary(64) NOT NULL to refer to a PHID
• the unique key should provide a name for the index

[liamzdenek]

Resolved in 9eedf2d02f8e1e9017b574f482144c7cc27d1e00

[zarvox]

Looks like it's still complaining about mismatched nullability:

Target                                             Error
phabricator_user.user_mapper.phabricator_user_phid Wrong Nullable Setting

 SCHEMATA ERRORS 

The schemata have errors (detailed above) which the adjustment workflow can
not fix.

If you are not developing Phabricator itself, report this issue to the
upstream.

If you are developing Phabricator, these errors usually indicate that your
schema specifications do not agree with the schemata your code actually
builds.

If you intend for it to be definitely not null, then I think you drop the ? in https://github.com/liamzdenek/phabricator-sandstorm/commit/9eedf2d02f8e1e9017b574f482144c7cc27d1e00#diff-9bd11836aca3a1c70fb0bf0c58378047R15

[liamzdenek]

Ooops, that's what i get for distracted coding. Fixed.