Problem: the message handler for job-list.stats-get handles a
response failure by sending an error response, which will also
likely fail.

Just log the error and proceed.

Problem: the job eventlog is needed for future changes to allow
inactive jobs to be obtained via the journal.

When creating a job from the KVS, simply keep the eventlog that is
passed into job_create_from_eventlog().  When creating a job from
scratch, create an empty one, then append events to the eventlog
each time one is posted via event_job_post_entry().

Problem: test code cannot look at the eventlog kept in memory
by the job manager.

Provide access via the job-manager.getattr RPC (key="eventlog").

Problem: consumers of the journal have to scan the KVS, a costly
operation, to obtain the full set of job IDs and their job state,
then reconcile possibly overlapping events received in the journal.
This protocol can be simplified now that the job manager stores
inactive jobs and their eventlogs.

Change the journal response message payload from:
  {"events":[
    {"id":I "eventlog_seq":i "entry":o}
    {"id":I "eventlog_seq":i "entry":o}
    {"id":I "eventlog_seq":i "entry":o}
    ...
  }
to
  {"id":I "events":[
    o
    o
    o
    ...
  ]}
where 'o' is a RFC 18 eventlog entry.

Upon receipt of a request by a journal consumer, the job manager sends a
response message for each active job.  If the "full" flag is set in the
request, inactive jobs are sent also.  Once the events for existing jobs
have been sent, the job manager sends a sentinel response:
  {"id":FLUX_JOBID_ANY, "events":[]}
The purpose of the sentinel is to allow a journal consumer to delimit
the stream of historical events from new events, in case it wishes to
ingest all historical events as part of its initialization.

Following the sentinel, the job manager sends a journal response message for
each new event.

The per-job event sequence number and associated logic has been dropped
since now the potential for overlapping events between KVS and journal
has been eliminated.

The 'job-manager.journal-size-limit' config key is dropped since journal
streams are now generated directly than pushed through a shared list.

Problem: job-list sometimes takes a long time to initialize,
duplicating "KVS restart" work already performed by the job manager.

Drop the code for walking the KVS and processing each job's eventlog.
This was performed synchronously, delaying 'flux module load' and therefore
instance startup.  Instead, set full=true in the job-manager.journal RPC
and process the journal asynchronously.

The handy "pause" functionality which was added for testing is employed
to allow the initial onslaught of journal response messages to be consumed
(stored on a message list) quickly without processing.  Once the journal
sentinel is received, the backlog is processed all at once (without giving
control to the reactor during processing), then the module is "unpaused"
and begins processing job events normally.  job-list already employs an
open loop "eventually consistent" model so the fact that queries could be
received in parallel with receiving the journal backlog should pose no
correctness problems per se.

Since there is now only one source of job events, the problem of
synchronizing two event sources that was solved with a sequence number
is no longer a problem.  Drop the sequence number.

Now there is only one code path for processing events in job-info: the
one for processing "live" events.  Since the order of arrival of jobs
in the initial journal backlog is non-deterministic (based on order
of job manager hash traversal rather than temporal order), job-list cannot
rely on that order.  Use zlistx_insert() instead of zlistx_add_end() to
add jobs to the running and inactive lists.  The former inserts in the
defined sort order while the latter ignores the defined sort order.

Problem: the events_journal_stream test program still uses the
old journal protocol.

Update protocol.

Problem: t2210-job-manager-events-journal.t includes a test for the
now defunct event sequence numbers.

Drop test.

Problem: t2210-job-manager-events-journal includes tests for
job-manager.journal-size-limit, but that config key is no longer
supported.

Drop tests.

Problem: t2210-job-manager-events-journal watches the journal
but won't receive (initially) inactive jobs without specifying
full:true.

Add full:true to the job manager journal request.

Problem: two tests in t2260-job-list modify eventlogs in the KVS
then restart job-list, but that is no longer sufficient now that
job-list does not restart directly from the kvs.

Change the tests to reload the job manager also.

Problem: issues/t4331-job-manager-purged-events.sh ensures that
purged jobs are not listed in a new journal stream, but that is no
longer possible since journal streams are generated directly from
the current active and inactive job list for each consumer, not
from a shared list of events.

Drop test.

Problem: the journal-size-limit is no longer supported but it is
still documented in the man page.

Drop it from the man page.

Problem: requests received during the initial processing
of the journal backlog are processed without any job data.

Instead of using the existing 'pause' flag to defer initial journal
processing, add an 'initialized' flag.  The initialized flag can be used
by request handlers to defer processing until after the backlog has been
ingested.  Deferring requests while pause is true would break tests that
rely on events being paused but not requests.

Problem: the job_state code will need to call a function
that operates on the main context to process deferred requests,
but it doesn't have access to it.

Instead of passing in 'isctx', pass 'ctx', then change jsctx->isctx
uses to jsctx->ctx->isctx.

Problem: job-list requests should not be processed until the
module is fully initialized.

While jsctx->initialized is false, requests are placed on a queue.
When jsctx->initialized is set true after the initial journal backlog
processing, messages on the queue are requeued in the flux_t handle
for reactive processing.

Problem: job-list, the primary consumer of the job manager
journal, has to look up R and jobspec in the KVS, but the job
manager already has redacted versions of these in memory,
which should be suitable.

When generating the initial backlog, send them along if set in
the job structure.

When processing live events, send jobspec with the validate
event and R with the alloc event.

Problem: ENODATA is not treated specially (as per RFC 6) when
the journal RPC gets an error response.

Detect that case, log it, and stop the reactor without error.
Also, don't decode the eventlog initally, as it is not used yet.
Let any (unlikely) protocol errors be handled when the message is
processed.

Problem: when R and jobspec are obtained from the journal,
they do not need to be parsed from encoded json.

Add some new functions that operate directly on job->jobspec
and job->R, which should be set from the journal request
continuation:

job_parse_jobspec_cached()
job_parse_R_cached()

Problem: now that the journal provides copies of jobspec and R
(redacted), it is no longer necessary to request those artifacts
from job-info.

Short-circuit the asynchronous fetching of jobspec and R.
Process them immediately in the DEPEND and RUN states, respectively.

Problem: job-list no longer looks up R and jobspec asynchronously
so there is no need to keep a list of active futures.

Drop the list.

Problem: job-list now obtains the eventlog, R, and jobspec
exclusively from the job manager journal, but tests try to
elicit various errors by corrupting those objects in the KVS
and restarting job-list.

There is not a way to get corrupted objects past the job-manager,
so just drop those tests.

Problem: code still exists for deferring job updates until
job-info lookups of R or jobspec have completed, but now that
those objects are included in the journal this cannot happen.

Drop unnecessary code.