Enable setting event number from inside JFactory::Process

[RaiqaRasool]

Currently, JFactory::Process receives a const JEvent&, which prevents modifying the event directly. This becomes a limitation when delegating data parsing to factories.

• If parsing is done in the event source, events are processed sequentially.
• If parsing is done in the factories, it can be parallelized, which is more efficient.

However, when parsing happens in factories, the event number can only be extracted after parsing, and there is no way to update the JEvent with this information.

Example scenario:

void JFactory_FADC250::Process(const JEvent& event) {
    LOG_DEBUG(GetLogger()) << "Inside Process() with run_number=" << event.GetRunNumber()
                           << ", event_number=" << event.GetEventNumber();

    // Get the EVIO event
    std::shared_ptr<evio::EvioEvent> evio_event = m_hits_in().at(0)->evio_event;
    
    // Parse EVIO data
    auto evio_event_parser = std::make_unique<EvioEventParser>(evio_event);
    evio_event_parser->parse();
    
    // Desired: set event number after parsing
    // event.SetEventNumber(evio_event_parser->getEventNumber());
}

Motivation

To allow users to implement data parsing inside factories (for parallelism and performance) while still being able to set the event number extracted from raw data.

[nathanwbrei]

This is an interesting problem, I'd like to think about it for a bit more. For now you can just use const_cast.

[nathanwbrei]

Here's an unorganized brain dump that I'm putting here simply so the thoughts don't get lost:

• This may be an argument for keeping "parallel event sources" around after all. The EVIO parsing code seems reasonably tightly coupled to the EVIO event source, so one could argue they belong together anyhow and we should just give up on using factories for parsing EVIO blocks.

• On the other hand, parallel event sources still have one big problem that prevents me from recommending using them: the declarative outputs are only usable on the sequential part. Anything we do to bring back declarative outputs that are usable in parallel is basically reinventing factories.

• One critical property of factories that we need to preserve is that data, once written, doesn't get modified by other components. This is actually doable if JEvent::m_event_number is a capturing property, i.e. it can only be set once. This would require us to distinguish between event numbers that are set by default vs those set by the user, and we'd probably want to make that information available to the user.

• The other critical property of factories is that we can't make any assumptions about what order they are run in. This means that we can only guarantee that another factory will observe the correct event number if the factory that sets the event number is an input (transitive or not) to any other factory that requests the event number. This is doable but ugly.

• The ugliness of trying to have parallel declarative outputs for JEventSources is closely related to the ugliness that is JEventSource::GetObjects. A clean solution for one would handle both use cases. Since the odds of being able to deprecate GetObjects() completely are slowly trending towards zero, maybe it makes sense to design an improved GetObjects() that also handles this use case.