Minor version: fix several issues, upgrade is recommended

Bug fixes:

• File Watcher option fixed (taskrunnernodb)
• Database issues fix
• Fix testing (web)
• Fix Elasticsearch client (extensions for JRE >= 8)
• Upgrade of external dependencies
• Support command OPTS before Login (Gateway FTP)
• Allow to specify Cipher and Protocols (Gateway FTP)

Minor version : improving performances

Improve performances during authentication

Once a client is connected and authenticated, as long as the connection stay valid, the authentication process
could be skipped since the remote partner is already authenticated.
Note however that this optimization might not be compatible with R66 proxy based partner, since the connection might be
shared among several real partners over the R66 proxy.
To disable this, specify the option -Dopenr66.authent.noreuse=1

Improve Database update number of calls

During initialization of the transfer, many updates are done, most of all are not essential (if anything goes right).
So, except if something wrong happened, updates during initialization are minimized (from 6 to 2 roughly).

Improve check of path for config, in, out, archive, work to be under base directory

In order to prevent "Chroot defect", the global configuration and the rules configuration are checked up against base directory.
They must be relative subdirectories.
Note it is still possible to mount or symbolicly link to another place, but the "virtual" directory must be a subdirectory under the base one.

Fix issue #103

Possibility to change Transfer ID to use Long GUID instead of SQL Sequence

Some users sometimes erazed their database, loosing the current sequence value for the transfer ID, giving issues when trying to contact partner which will have the very same ID for a new transfer, which is not allowed (unicity). While it is simple to fix by setting the sequence to start to a number higher than the biggest one already used, we decide to make 2 changes:

1. SQL Sequence will be created with starting value as current time (EPOCH as long), thus preventing from already used id
2. Propose another way to assign id, using a Long GUID, which should prevents this kind of issue too.
   To set this active, you have to specify -Dopenr66.transfer.guid=1 as JVM arguments.

We also add an option to ServerInitDatabase as -minimalSeq value, where value can be the value to start from when assigning new transfer ids.

Fix issue #102

Also:

• Upgrade dependencies
• Fix bad init of some Benchmarks
• Fix bad check within tests (issue #100 and issue #99) and improve passing tests under heavy loaded CICD (issue #104)
• Fix bad behavior on some functions where role has to be correct but then wrong exception occurs (create
  NoCorrectAuthentication)
• If supported, MariaDB will use native SQL Sequence (from 10.3)
• Clean up code

Some Benchmark Results Update

Waarp R66 Benchmarks

• Loop Benchmarks : 2 Waarp Servers, 1 with PostgreSQL as Container, 1 with H2 Database on the same server with 2000 files of size average of 250 KB
  • TLS efficiency: up to 149 trasfers/second
  • No TLS efficiency: up to 150 transfers/second
• Dual Waarp servers on the same host with the same PostgreSQL Database as Container and Filesystem with one Client on the same server with 4000 concurrent transferts of size average of 250 KB
  • 1 server: 85 transfers/second with 25% CPU usage
  • 2 servers: 178 transfers/second, so 100% more than 1 server in cluster, 40% more compare to 1 server only, with 45% CPU usage
  • 4 servers: 346 transfers/second, so 100% more than 2 server in cluster, 180% more compare to 1 server only, with 80% CPU usage
• Big file transfers: up to 300 MB/s (2 400 Mbps)
• Improvements: using a 2 CPU (4 vcore) and 16 GB RAM laptop with 2 instances of Waarp R66 on it using TLS
  • v3.0 ~ 30 transfers/s 100% CPU,
  • V3.2 ~60 t/s 100% CPU,
  • v3.5.2 ~71 t/s 100% CPU,
  • v3.6.0 ~ 100 t/s 90% CPU
  • v3.6.1 ~ 124 t/s 80% CPU
  • on a 4 CPU (8 vcore), 2 instances: v3.6.1 ~ 150 t/s 35% CPU

Gateway FTP Server benchmark

• 8 threads (4 core), 16 GB Memory
  • Single FTP client
  • Using Waarp FTP client (based on FTP4J): with 1KB file
    • Passive: 77 transfers/s
    • Active: 118 transfers/s
  • Same with 100 concurrent clients
    • Mixte Passive/active: 4200 transfers/s

IMPORTANT: DEB, RPM and other distribution (except JAR) are not yet official.

New major version

Add S3 Support for Read or Write File to R66

Only available from JRE 8 (so not with JRE 6) due to unerlying S3 client used (Minio-Java),
it allows to extend the Waarp R66 tasks with new operations:

• S3 GET (and eventually S3 DELETE) from remote S3 file and implicit R66 RENAME
• S3 PUT (and eventually R66 DELETE) to remote S3 file
• S3 DELETE remote S3 file

Note that for GET task types as pre-task, as it may be the source file for a transfer,
either in SEND mode or RECV mode (push or pull),
the mode for the Rule shall be SENDTHROUGHMODE or SENDMD5THROUGHMODE,
respectively 5 or 7, or RECVTHROUGHMODE or RECVMD5THROUGHMODE,
respectively 6 or 8, since the file does not exist at startup.

This change allows also to add new tasks to the existing tasks by adding
one or many TaskFactory to the TaskType object within WaarpR66 using an
extra Jar.

In order to have a full version for Waarp for JRE 8 and JRE 11, 2 additionnal
WaarpR66 with full dependencies are created, named WaarpR66-S3.

Add Remote monitoring in Push mode

Currently, only Pull mode (request on REST API) is available to integrate
status of transfers from Waarp R66. It is also available to connect directly
to a remote Elasticsearch but using JRE 8 or 11 versions only.

This add the possibility to configure each Waarp R66 servers to send
through HTTP(S) requests to a remote API REST (configurable)
every x delay (configurable) with the last R66 transfers informations
based on Stop Date (last updated information date) as a Json array
as

 {
   "results" : [
    { transfer information as Json },
    ...
  ],
 }

Each transfer informations as:

 {
   "hostId":"server1",
   "waarpMonitor":{
     "to":"2021-04-08T17:29:42.690Z",
     "from":"2021-04-08T17:29:41.676Z",
     "index":"server1"
   },
   "blockSize":1048576,
   "stop":"2021-04-08T17:29:41.965Z",
   "errorMessage":"Unknown status",
   "filename":"hello12560",
   "type":"r66json",
   "stepStatus":"Unknown",
   "transferInfo": "{\"follow\":-8739926495694136052, \"ORIGINALSIZE\":12560},
   "originalFilename":"hello12560",
   "originalSize": 12560,
   "specialId":-9223372036854775807,
   "followId":-8739926495694136052,
   "requester":"server1",
   "globalStep":"NOTASK",
   "ruleName":"loop",
   "start":"2021-04-08T17:29:41.954Z",
   "requested":"server2",
   "fileInfo":"Test Loop Send 12560 {\"follow\":-8739926495694136052}",
   "status":"TOSUBMIT",
   "errorCode":45,
   "retrieve":true,
   "globalLastStep":"NOTASK",
   "step":-1,
   "uniqueId":"server1.server1.server2.-9223372036854775807"
 }

And in the Headers of Http POST request:

 X-WAARP-ID : hostId
 X-WAARP-START : Date Time From Interval
 X-WAARP-STOP : Date Time To Interval

This can be used for instance with a Logstash service that sends back to an
Elastic index, using for instance waarpr66.waarpMonitor.index.date as final index.

Add configuration:

• Within server set
  • pushmonitorurl http://127.0.0.1:8999
• URL for remote REST Service
  • pushmonitorendpoint /log
• Remote End point for REST Service
  • pushmonitordelay 1000
• Period of check to push information on changed transfers statuses
  • pushmonitorkeepconnection True
    • If True, the HTTP(S) connection will using Keep connection, while False means
      closing connection after each POST (default True)
  • pushmonitorintervalincluded True
• If True, the Json will contain interval information (from, to, suggested partial index name) (default True)
  • pushmonitortransformlongasstring True
    • If True, the Json will transform "Long" as "String" (for ELK) (default False)

An example of Logstash configuration is given in WaarpR66/src/main/config/logstash-r66.conf

Benchmark shows only 1% of degradation using 4 vcore.

Other new functionalities

• If a certificate is no longer valid, Waarp will raised a warning but will not stop the execution
• Waarp R66: the Web administration allows to modify or create an transfert for the current server
• Waarp R66: the Web administration allows to search transfers according to "follow id"
• Enhanced facility to add new tasks to Waarp R66
• Add compression task based on ZSTD algorithm (fast and efficient)
• Add compression possibility (inactive by default) on network level using again ZSTD algorithm
• JRE up to version 16 compatibility ensured (using JRE 11 package)
• Add automatic packaging (not official yet) of RPM, DEB, TGZ and ZIP, including documentation in HTML and PDF
• Gateway FTP: lets the possibility to specify if PASSIVE and ACTIVE modes are accepted:
  • in limit, activepassive n where n could be -1 = passive, 1 = active, 0 = both

Fix Doc and improve performances

• LocalExec increase thread possibility
• Change minimal / maximal threads for retrieve
• Increase runlimit to 50 000
• Improve Client Thread / Server Thread
• Improve Buffer using ioBuffer for sent parts
• Add Benchmark tests on Multiple scenarios (multiple servers, Monitoring, S3, FTP...) and also ascendant compatibility using
  v3.5.2 as reference
• Fix issue on Oracle JDBC driver from Maven Central inspired from Pull Request #92
• Fix issue #91 on profile option description in README.md, inspired from Pull Request #93
• Fix Json and XML issues
• Change to Saxon when possible
• Fix various FTP issues (both server and clients sides)
• Improvements on SQL requests and Indexes (mainly for Waarp R66)
• Improvements on memory usages
• Improvements on documentation
• Creating a full build (jar, RPM, DEB, ZIP, TGZ) from Maven
• Upgrade dependencies

Some Benchmark Results

Waarp R66 Benchmarks

• Loop Benchmarks : 2 Waarp Servers, 1 with PostgreSQL as Container, 1 with H2 Database on the same server with 2000 files of size average of 250 KB
  • TLS efficiency: up to 127 trasfers/second
  • No TLS efficiency: up to 133 transfers/second
• Dual Waarp servers on the same host with the same PostgreSQL Database as Container and Filesystem with one Client on the same server with 4000 concurrent transferts of size average of 250 KB
  • 1 server: 89 transfers/second with 30% CPU usage
  • 2 servers: 192 transfers/second, so 100% more than 1 server in cluster, 40% more compare to 1 server only, with 60% CPU usage
• Big file transfers: up to 300 MB/s (2 400 Mbps)
• Improvements: using a 2 CPU (4 vcore) and 16 GB RAM laptop with 2 instances of Waarp R66 on it using TLS
  • v3.0 ~ 30 transfers/s 100% CPU,
  • V3.2 ~60 t/s 100% CPU,
  • v3.5.2 ~71 t/s 100% CPU,
  • v3.6.0 ~ 100 t/s 90% CPU
  • on a 4 CPU (8 vcore), 2 instances: v3.6.0 ~ 127 t/s 30% CPU

Gateway FTP Server benchmark

• 8 threads (4 core), 16 GB Memory
  • Single FTP client
  • Using Waarp FTP client (based on FTP4J): with 1KB file
    • Passive: 77 transfers/s
    • Active: 118 transfers/s
  • Same with 100 concurrent clients
    • Mixte Passive/active: 4200 transfers/s

IMPORTANT: DEB, RPM and other distribution (except JAR) are not yet official.

Minor fixes and optimizations

This minor update contains several improvements.
Note : jar version is for Java 6, jre8-jar for Java 8, jre11-jar for Java 11.

Improve network closing when necessary and using native ByteBuf

Reason:

While network connections were closed normally, sometimes they were closed too early
in the sense that another "local" connection (local channel) could still used it.
Moreover some ByteBuf were wrapped of byte arrays, which is not optimized for Netty.

Changes:

Improve testing on reusability of network connection and centralization of this
process, such that all local closings use the same algorithm and codes.

This change allows to keep as much as possible existing connections if they can be
reused soon. If not, within a certain delay (Timeout), the connection is closed.

Byte Arrays are now written directly within a real ByteBuf from pool.

Result:

Now loop based IT tests or direct multi transfers give good performances and no more issues.

• Recv Direct using 3000 files of 360 KB gives an average of 40 transfers per second,
  while not optimal since even if multi-threaded, there is a latence on thread creation
  and execution
• Loop transfers (from one server to another and repeating) of 700 concurrent files in average
  of 360 KB gives an average of 77 transfers per second.

This last result is a good start for a real benchmark (211 Mbps, roughly the speed of disk).

Conditions of benchmarks:

• 2 and 4 cores, 8 GB RAM, 200 Mbps disks capacity
• 2 Waarp servers started, 1 PostgreSQL database started (docker) on the same server

Comparisons on loop transfers:

• v3.5.1 : 4 cores gives about 30 transfers/second
• v3.5.2 : 2 cores gives about 50 transfers/second
• v3.5.2 : 4 cores gives about 76 transfers/second (roughly the disk speed), 4500/minute

One can expect a non linear scalability extending vertically the server. However note that
these benchmarks are on the same server so:

• almost no latency between services (the 2 Waarp servers and the database)
• but still 3 high consuming services on the same 4 cores (2 Waarp servers, each about 45%
  of CPU, and 1 PostgreSQL database about 10% CPU with about 2 Mbps SQL traffic network
  bandwidth)

Probably 4 cores with 8 GB for the JVM and only one Waarp server, having in a separate
host the PostgreSQL database, and of course the second Waarp server with its database
somewhere else, shall give better performances, about 150 transfers/second
7800 transfers/minute).

Scalability can be both vertical (increasing CPU mainly, but also Memory) and
horizontal (using a loadbalancer, a shared database and a shared efficient
filesystem).

Improve file canRead method

Since filesystem is sometime unsynchronized with Java, this method tends
to try to leverage this issue by trying multiple times if not OK the first
time (at most 30 ms).

Allow Windows FTP client to connect to FTP Gateway

Windows FTP client seems to send immediately after the connexion an OPTS command
while it shall be done after the authentication step. We allow this special command to occur
just before the connexion, such that Windows FTP client can access to the FTP Gateway.

Fix POM dependencies

New minor version - Fix for speedup and Compatibility from JRE 6 to JRE 11 and other improvements or fixes

This minor update contains several improvements:

Speedups:

• Remove or decrease extra sleep command while there are no more needed
• Digest by packet is optimized (mode being SENDMD5 or RECVMD5, while digest could be any from CRC32, ADLER32, MD5, MD2, SHA1, SHA256, SHA384, SHA512)
• Reduce the Local Digest computation when not needed (while Global Digest is done)
• Cache DB access for Business, Host and Rule only
  • Note, this is deactivated if the server is in "MultipleMonitor" mode (since Cache can be not coherent).
• Improve TaskRunner for specific case of Update on rank update (only rank and stop date are updated, not all fields).
• Reduction of latency

Fixes:

• Bad programming practice corrections
• Improvement of documentation
• Improvement of Rest V2 Service to include information from FileMonitoring
• Improvement of logs (performances and adapted level)
• Upgrade of external dependencies

New versions for JRE 6, 8 and 11 separately provided from now:

• JRE 6 to JRE 11 compatibility, including 3 kind of packages:
  • Waarp*.jar for JRE6,
  • Waarp*-jre8.jar for JRE8
  • Waarp*-jre11.jar for JRE11

General recommendations for speedup
If one has a very limited resource server and wants to ignore all consistency checks, then :

• using transfer with no MD5 mode will allow to improve about 10% to 20% the speed of transfer.
• disabling final local check (localdigest to False) will allow to improve about 20% more to the speed of transfer (since optimization is already there).
• disabling global check (globaldigest to False) will allow to improve about 25% more to the speed of transfer.

So globally, one can improve up to 50% (we were able to reach 110 MBPS or 880 MbPS).

However, it is not recommended to have no check at all during transfers.
So we recommend to at least active global digest (globaldigest to True or unset as default value), which will bring about 30% of improvements of speed (compared to all options actives).

Other recommendations

• Java arguments: use -Xms2048m -Xmx2048m
• XML configuration:
  • serverthread to nb of core (default) or less if you want to limit the CPU usage
  • clientthread to 10 * serverthread (default) or less if you want to limit the CPU usage
  • ignore or set usefastmd5 to False (default) (not anymore efficient)
  • digest to 7 (SHA-512 while MD5 being the default) or if you accept more collisions, 2 for MD5 but really more efficient (about 50%)
  • ignore or set globaldigest to True (default) (consistency check)
  • localdigest to False (True is the default) (optional consistency check, this fix limits greatly its impact however)
  • ignore or set runlimit to 1000 (default) or less if you want to limit the CPU usage (concurrency of submitted transfers, do not set to lower than 10)
  • blocksize to a multiple of 16KB (64KB being the default, but do not set more than 256KB) (the higher, the smaller the number of packets)
  • memorylimit to a value acceptable for HTTP and REST services (default 1GB, could be set to less)
  • sessionlimit and globallimit to an acceptable bandwidth limitation (for instance 100 MBPS), default being no limit (note: limit is in Bytes per second and not bits per second)
  • ignore or set usenio to False (default) (no more improvement with true)
  • Use CPU limitation to adjust bandwidth automatically to prevent CPU high consuming over 60% (here for the example since 0.6) (global bandwidth is adapted automatically)
    • usecpulimit to True (default False, as for usejdkcpulimit that could be ignored),
    • cpulimit to a value less than 1.0 (0.6 for instance),
    • connlimit still to 0 (default, unlimited):

New major version - Multiple network interfaces selection and Follow Id improvement

New version v3.5.0:

• New functionality: Ability to specify the network interfaces to use for R66 protocol and HTTP/HTTPS administration interfaces
• Improve Follow Id functionality
• Various fixes and cleaning of code
• Major improvement on memory consumption

New major version - ICAP and Follow Id support

New functionalities:

• The ICAP Task Type allow to launch a ICAP scan file command with the following options:

  -file filename
  -to hostname
  [-port port, default 1344]
  -service name | -model name
  [-previewSize size, default none]
  [-blockSize size, default 8192]
  [-receiveSize size, default 65536]
  [-maxSize size, default MAX_INTEGER]
  [-timeout in_ms, default equiv to 10 min]
  [-keyPreview key -stringPreview string, default none]
  [-key204 key -string204 string, default none]
  [-key200 key -string200 string, default none]
  [-stringHttp string, default none]
  [-logger DEBUG|INFO|WARN|ERROR, default none]
  [-errorMove path | -errorDelete | -sendOnError]
  [-ignoreNetworkError]
  

  Then if r66send command in case of -sendOnError option is specified, the
  very last option of ICAP must be "--" then followed by usual r66send
  options.

Also available a command line: IcapScanFile

-file Specify the file path to operate on (f arg is EICARTEST, will send a fake virus based on EICAR test)
-to Specify the requested Host
[-port ] Specify the port on remote host to use
-service | Specify the service on remote host to use
-model arg Specify the model of service on remote host to use
[-maxSize ] Specify the Max file size to use
[-previewSize ] Specify the Preview size to use
[-blockSize ] Specify the Block size to use
[-receiveSize ] Specify the Receive size to use
[-timeout in_ms] Specify the timeout in ms
[-keyPreview ] Specify the key for Options to validate
[-stringPreview ] Specify the substring for key for Options to validate
[-key204 ] Specify the key for 204 ICAP to validate
[-string204 ] Specify the substring for key for 204 ICAP to validate
[-key200 ] Specify the key for 200 ICAP to validate
[-string200 ] Specify the substring for key for 200 ICAP to validate
[-stringHttp ] Specify the substring for HTTP 200 ICAP status to validate
[-errorDelete | Specify the error delete action if wrong scan
-errorMove | Specify the path to use if wrong scan
-sendOnError] Specify the wrong file will be send somewhere else
[-ignoreNetworkError] Specify that a network error will gives a result of OK
[-logger ] Specify the level of log between DEBUG | INFO | WARN | ERROR

It returns exit value as follow:

0: File is OK
1: Bad arguments
2: ICAP protocol error
3: Network error
4: File is KO
5: File is KO but bad access to file during post error action

• Option follow

This option follow allows to add a specific field in the transfer information such that
in an externa tool, it is possible to link multiple transfers as hop of the same file.

For instance, sending a file from host A to host B, which will autoatically resend this file
to host C, and then to host D, all transfers will have a special information within the
transfer information such as {'follow': number}. This number will be kept the same
in each and every transfers related to the first one.

This option is enabled by default. Then, for the first transfer, Waarp will allocate
a new specific Id of follow. Then all other transfers related to the first one will
have this one.

If yoy don't want this option enabled, just add -nofollow option.

• Add Rest V2 options for FollowId

The REST V2 interface integrates the search options based on followId
(GET /v2/transfers/?followId=number).

number being possibly a long number, it is adviced to manipulate
it as a String.

Add a special finder in DbTaskRunner for this
(getSelectSameFollowId(followId, orderByStart, limit)).

Evolutions

• Default network limitation is now set to 100Gb for global limitation and 1Gb for unitary transfer
• Ram limitation for Rest and Web services is set to 1GB (instead of 4GB previously)

Fixes:

• Regex path filter
  Originally, the regex filtering in the filewatcher was only able to match filenames.
  In recursive mode, it was impossible to math a subpath.

During the 3.1 development cycle, I pushed some changes to match full paths. However, this had the side-effect to only allow file matching if the regex started with .* to match the subpath (ex: .*.csv). I.e. the regex myfile.txt whould not match subpath/myfile.txt.

This PR allows both regex to work as expected:

- myfile\.txt matches myfile.txt as well as subpath/myfile.txt
- subdir/.+\.txt matches subdir/myfile.txt

• Fix Map manipulation within Transfer Information to not loose other informations
  than JSON extra information (various usages).

• Fix client issue #56

• Limit memory impact

  • For Server, change Web, Web Admin, REST V1 and V2 configurations (threads)

    • For all, the old (unused) argument memorylimit to a value like 100000000 (100MB)
      can be used to limit Memory impact
    • For REST V2: improve configuration, in particular network fine configuration and workers
    • One could add the standard option -Xmx1g to limit to 1GB of memory.
      It is possible for not heavy loaded Waarp server to limit to 512 MB (-Xmx512m), but
      one should not make it smaller.
    • Adapt the XML configuration according to context:
      • runlimit to a number between 100 to 1000 (at most 1000)
      • serverthread to 1 to 32 (at most 2x number of cores)
      • clientthread to 10 to 100 (at most 10x serverthread)
      • memorylimit to a number between 100000 to 1000000 (100MB to 1GB) for web and Rest purpose only
      • Don't activate unused sub-services such as: REST (V1 and V2), SNMP, THRIFT, CPU limitation, Bandwidth limitation

  • For client only, one can specify in XML configuration file the following items to limit
    memory impact

    • runlimit to 1
    • serverthread to 1
    • clientthread to 1
    • One could add the standard option -Xmx128m (128MB but not less) for such limited client
      with no extra support activated (no CPU limitation, others like Thrift, Snmp and Rest
      support being off for client). Note however that it is still recommended to allow at
      least 512 MB of memory (-Xmx512m).

  • Reduce memory and cpu usage in Hash computations

  In reference to issue #52 (OOME on Pull request).

• Upgrade dependencies

• Introduce a PrintOnlyWarningLogbackStatusListener to disable info or debug
  startup information on Logback initialization, but not warn or error.
  Enhance the log initialization.

• Fix minor cosmetic for tests

Waarp All Fix regressions 3.3.4 (2020-06-02)

Fix in Waarp R66

• Fix issue on unlimited connection retry attempts
• Fix issue on wrong argument on requester host
• Fix Doc for HTTP module
• Fix Shaded Jar (all-dependencies)
• Fix wrong database support on DbHostConfiguration
• Fix issue #35 Listing/CancelRestart SpecialId sort and Clear
• Fix issue #37 Admin attribute R66 REST V2 authaurization
• Fix SonarQube report with last XML format
• Fix documentation example
• Fix the Header used for signature in Rest v2
• Fix the API browser for REST v2
• Fixes the HMAC Authentication of RESTv2
• Fix for Block Size

Fix in Waarp GW FTP

• Fix Shaded Jar (all-dependencies)
• Fix SonarQube report with last XML format

Other Fix

• Fix external dependencies and style

Waarp All Fix regressions 3.3.3 (2020-05-12)

Fix in Waarp R66

• Fix issue #19 on missing DbRule for DbTaskRunner
• Fix issue #22 for Path in Rule under Windows OS
• Fix issue with unlimited retries when transfer raises a "no connection" error, recovering original behavior with 3 retries maximum

Fix in Waarp GW FTP

• Fix Issue #24 GW FTP stops immediately after startup

Fix in Waarp R66 and GW FTP and R66Proxy

• Fix issue #26 on DB Connection closed in Admin

Other Fix

• Fix external dependencies and style

Waarp All Fix regressions 3.3.2 (2020-04-22)

Fix documentation

• Add deprecation of dbcheck to the doc
• Formatting
• Move some content in appropriate sections

Fix Rest API (R66)

• Fix test on Rest V1
• Fix Rest V2 returning missing versionR66 and versionBin
  • Version 1 is not anymore correct for version since automatic update of database fix long time ago
• Fix Rest memory issue
• Fix R66 Finite state (small)
• Fix Dao issue on Insert or Update from Json from REST API

Fix WaarpHttp Module

• Missing methods on various objects
• Missing class (HttpDeleteSession)

Other Fix:

• External dependencies upgrade