Problem: The split_string () helper function can only accept a list of
queues to parse when unpacking user/bank information from the
flux-accounting DB, but there also exists a need to be able to parse a
list of projects as well. Since both lists can be parsed the same way,
this helper function should be expanded.

Expand the split_string () helper function to accept either a list of
queues or a list of proects to parse through when unpacking user/bank
information.

Add an unpack of the "projects" and "def_project" columns for each
association when unpacking them in the rec_update_cb () function.

Add a new callback to unpack information from the project_table and
store it in a vector of projects to be used for project validation
and annotation.

Add information from the project_table and the projects column in the
association_table to the bulk update script that sends user, bank, and
queue information to the multi-factor priority plugin.

Add "active", "projects", and "def_project" key-value pairs to the fake
payloads sent to the multi-factor priority plugin in a number of the
sharness tests.

Problem: The sample user payloads sent to the plugin grow longer than
wanted in the sharness test files with the addition of the "project" and
"default_project" fields.

For the tests that have these sample payloads, create a new folder in
the t/ directory that stores these JSON payloads permanently in a file
instead of creating them within the test.

Add project validation to the validate_cb () function, which checks
that if a project is specified by an association when a job is
submitted, it:

1) is a valid project to submit jobs under, and

2) is a valid project for the association to submit jobs under.

If either one of these checks fail, the job is rejected with a message
including the project name.

Add a helper function to mf_priority.cpp that adds the project name for
a user/bank's job to the jobspec via jobspec-update under
attributes.system.project.

Problem: If a user submits a job under a default project, there is no
way to tell which project they submitted their job under because it does
not get posted to jobspec.

Add a jobspec-update of the user/bank's default project name when the
job is in the job.new callback.

In the event where a user/bank submits a job before any information is
loaded to the priority plugin and their job is held in PRIORITY state,
add a jobspec-update of the user/bank's default project name in
job.state.priority IF their default project name is not "*" ("*" is
the default project name if a user is added to the database with no
projects).

Add the projects and def_project fields to the list of information
returned for each association in the plugin.query callback.

Add the projects and def_project key-value pairs to the expected files
for t1019-mf-priority-info-fetch.t.

Problem: There are no tests for project validation and annotation in the
multi-factor priority plugin.

Add some tests.

Problem: Now that the priority jobtap plugin supports jobspec-updates of
both banks and projects, the "jobspec-update" event in the eventlog
holds both of these updates on one line, which breaks the assumption in
t1029-mf-priority-default-bank.t that the jobspec-update of a user's
default bank will be surrounded by brackets {}.

Remove the outer brackets from the tests in
t1029-mf-priority-default-bank.t that grep for a certain bank.