Fix \Drupal\advancedqueue\Plugin\AdvancedQueue\Backend\Database::enqueueJobs() to use transaction correctly

Heck. Just realized how out of date my branch is with dev.

Just in case I lose it, this is how I implemented things on my end (on a much earlier version of 7.x-1.x):

  public function createMany($items) {
    $query = db_insert('advancedqueue')
      ->fields(array(
        'name',
        'uid',
        'title',
        'data',
        'created',
        'status',
      ));

    foreach ($items as $data) {
      $query->values(
        array(
          'name' => $this->name,
          'uid' => is_array($data) && isset($data['uid']) ? $data['uid'] : $GLOBALS['user']->uid,
          'title' => is_array($data) && isset($data['title']) ? $data['title'] : t('Unnamed item'),
          'data' => serialize($data),
          // We cannot rely on REQUEST_TIME because many items might be created
          // by a single request which takes longer than 1 second.
          'created' => time(),
          'status' => ADVANCEDQUEUE_STATUS_QUEUED,
        )
      );
    }

    return (bool) $query->execute();
  }

This patch refactors the item creation by pulling it into a separate function so that it can be used in both the createUniqueItem() and createMany functions. It also pulls the grabbing of the schema and setting of the $title_max variables into the constructor so that it doesn't happen on every call.

Tests to follow, but I'm curious for any feedback on this approach before I spend more time on it.

Looks like I goofed on the name of the preparation function. Patch updated accordingly.

Patch in #4 didn't work. #5 does! Was not calling values() was calling fields(), instead. This only created one at a time.

Ack. Nevermind. Do this instead.

Sheesh. Having problems, obviously. OK. Only create the query if we have something to do.