receiver incorrectly handles multi-source transfers
Motivation
----------

In case of multi-source transfers, receiver analyzes the message even if the job didn't yet finish:
https://github.com/rucio/rucio/blob/8acc9c9b873eef1d7e3b081821665ee03b95f4a0/lib/rucio/daemons/conveyor/receiver.py#L93

If the the message concerns one failed source, this results in a transition of the transfer to a failed state :  
https://github.com/rucio/rucio/blob/8acc9c9b873eef1d7e3b081821665ee03b95f4a0/lib/rucio/transfertool/fts3.py#L523

One may be miss-leaded, me included until now, that the `t_final_transfer_state` field is related to the job_state, but it  doesn't seem to be the case on FTS side. It depends on the file_state and the job state may not yet be final: 
https://gitlab.cern.ch/fts/fts3/-/blob/a34b78420e7f06aebca4f468e39312189e9e1454/src/url-copy/LegacyReporter.cpp#L214

This means that the receiver may transition the file to a failed state even if the job is not yet completed. 



diff --git a/lib/rucio/daemons/conveyor/receiver.py b/lib/rucio/daemons/conveyor/receiver.py
index 842b1fc00..fc10b55ce 100644
--- a/lib/rucio/daemons/conveyor/receiver.py
+++ b/lib/rucio/daemons/conveyor/receiver.py
@@ -73,9 +73,7 @@ class Receiver(object):
            and 'issuer' in msg['job_metadata'].keys() \\
            and str(msg['job_metadata']['issuer']) == str('rucio'):
 
-            if 'job_state' in msg.keys() and (
-                    str(msg['job_state']) != str('ACTIVE')
-                    or str(msg['job_state']) == str('ACTIVE') and 'job_m_replica' in msg.keys() and (str(msg['job_m_replica']).lower() == str('true'))):
+            if 'job_state' in msg.keys() and str(msg['job_state']) != str('ACTIVE'):
                 record_counter('daemons.conveyor.receiver.message_rucio')
 
                 self._perform_request_update(msg)
['lib/rucio/daemons/conveyor/receiver.py']