Remove use of BLOB storage in RMS

[chrisburr]

Do you see any downside to it ?

I think I agree with you, specifically:

• SourceComponent should be converted to VARCHAR instead of BLOB
• JEncode should be used instead of DEncode for making Arguments serialisable
• The Arguments can then also be converted to VARCHAR instead of BLOB

My only question would be how we deal with the actual upgrade/migration and I suspect it's invasive enough that it is something for v7r3.

Originally posted by @chrisburr in #5111 (comment)

Converting BLOB to VARCHAR for SourceComponent should be a no brainer from the DB point of view, since it is all string. For Arguments, up to now in DIRAC it has only been text serialized with DEncode so I guess that works too.

We should indeed get ride of the RMSEncoder and favour JEncode for the network serialization of the overall RMS objects, but the Argument field should stay in the DB with DEncode, since it will be tricky to migrate that. The problem mainly is that the encoding/decoding is not done in the Operation class, but scattered in the client code, which is a bit stupid. So if we want to change that (but do we ?), a first step is probably to factorize the encoding/decoding of Arguments into the Operation class.
(we had a general discussion about that here #4986)

Of course, the problem will always be the compatibility of old clients. Though for that we could finally make use of the clientVersion field sent in the dips connection arguments...

I somehow have the feeling that whatever modification we want to do with BLOB (in any DB), we are better of doing it BEFORE running actual python3 code

Originally posted by @chaen in #5111 (comment)