[DE-593] Support latest ArangoDB version

[apetenchea]

Scope & Purpose

Currently, the main branch is only tested against ArangoDB 3.7 single-server.
This PR bumps that version to 3.10.6. Due to that, additional changes were needed:

• make sure newly (since 3.7) are available
• adapt unit tests (some were broken from before, some became broken due to newer ArangoDB versions)
• decide the officially supported Python versions (we're going to support the default Python versions that come with the last two Ubuntu LTS releases)

Apart from bumping the ArangoDB version to 3.10.6, the CI will stay the same, until we decide regarding the CircleCI integration. Until then, I am using the tester.sh script locally for running more comprehensive suites. I ran everything against 3.9.10 and 3.10.6. Rest assured, this is not going to stay like that. I will push for a proper CircleCI.

Once this PR gets through, the plan is to add support for 3.11.

• 💩 Bugfix
• 🍕 New feature
• 🔥 Performance improvement
• 🔨 Refactoring/simplification

[geenen124]

Let's keep 3.9 and 3.11 in the test matrix?

[apetenchea]

Sure, I just added them back!

Let me explain my intention:
After discussing with Carsten, it turns out our goal is to focus our support and testing efforts on the Python versions that come with the last two Ubuntu LTS versions (3.8 and 3.10), as these are the most commonly used in our user base.
The current github action serving as CI is only spawning a single-server community instance and runs the single-server driver tests. That's it, no cluster nor enterprise checks.
Eventually, to do it properly, we'll have to test it against:

• single server community
• single server enterprise
• cluster community
• cluster enterprise

The officially supported ArangoDB versions are 3.9, 3.10 and 3.11 (soon). That gives us 12 combinations. Currently, I have arranged the setup for testing all of that locally. We could think of ways to shrink it down to 8 or so, but it's still not going to a short list. Adding the Python version as the "third dimension" of this matrix will make things even more complicated. Nevertheless, we must ensure that at least the officially supported Python version are checked. I could gather a reduced test-set that will be used for this purpose: validating the driver against the given Python version.

Nevertheless, for now it doesn't hurt to leave 3.9 and 3.11 in there. You've made a good point, thanks!

[geenen124]

This diff changes the function's default behavior. Before, computedValues was only present in results if body["computedValues"]'s value was non-null. A user could assume that computedValues is non-null if it's present in results, so this change is breaking.

Unless we're planning a major version release next, IMO we should keep the old behavior instead. What do you think?

[apetenchea]

Thanks for pointing that out! This change was made to make the tests pass, which seemed to have been failing before, because we would always expect computedValues to appear in the result, as long as it appears in the body.
For some reason, it was merged with the failing tests. I assume it was due to the fact that the CI never checked 3.10 before, it was only validated on 3.7 single-server.
It's possible that the tests were written with the wrong assumptions or the function's behavior isn't well-defined when it comes to null values in computedValues.

1. If we're confident that the tests are correct and reflect the intended behavior of our code, we can accept this change. Being new to the project, I used the tests as guidance, so this looked like more of a bug-fix to me. Note that for all other keys, their value will be reflected in result, as long as they are in the body. This was the only place where I could find this sort of check. It can be null in the JSON response, which translates to None in body, and the tests expect to see the same in result.
2. It is also possible that the tests were never adapted to the newly introduced keys in 3.10. In that case, we should revisit them and align them with the function's current behavior.

What are your thoughts on this?

[geenen124]

IMO we should align the test with the function's current behavior (because this behavior has already been released, and isn't buggy - as it's just about the presence of a key/value pair or not), but we should also make a note of this to revisit before a major release :)

[apetenchea]

I followed with your suggestion and reverted the way we calculate computedValues back to the old behavior.
It is unclear whether or not there should be None values in the driver's result. Some attributes are simply copied over to the result, while others, such as computedValues, are only processed if they are not None. In order to adapt the tests, I had to remove None values from both the result and the body before comparing them. There is a common function used to validate the differences between the request's result body and the expected result after it being processed by the driver: mock_verify_format

[codecov-commenter]

Codecov Report

Merging #247 (8f7d4bd) into main (2093a17) will increase coverage by 0.10%.
The diff coverage is n/a.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@            Coverage Diff             @@
##             main     #247      +/-   ##
==========================================
+ Coverage   98.46%   98.57%   +0.10%     
==========================================
  Files          26       26              
  Lines        3853     3853              
==========================================
+ Hits         3794     3798       +4     
+ Misses         59       55       -4     

Impacted Files	Coverage Δ
arango/backup.py	100.00% <ø> (ø)
arango/collection.py	96.47% <ø> (ø)

... and 1 file with indirect coverage changes