Updating documentation and deprecating old APIs

[erikbosch]

This PR covers the following:

• Trying to say something about the difference between v2 actuation and v1 "set target value" - that you cannot mix them. Off course - if we add some bridge between them we need to update the text
• It says in text that the old APIs are deprecated. I think this is what we want right.
• It makes sure that there are links to all documentation pages
• It remove some references to Kuksa Server. As that tool has reached EoL we should in the long run remove all references.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 59.33%. Comparing base (a5314a6) to head (b76184c).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #105      +/-   ##
==========================================
+ Coverage   59.23%   59.33%   +0.10%     
==========================================
  Files          33       33              
  Lines       16063    16067       +4     
==========================================
+ Hits         9515     9534      +19     
+ Misses       6548     6533      -15     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[rafaeling]

It also applies to list_metadata in kuksa.val.v2, see https://github.com/eclipse-kuksa/kuksa-databroker/blob/main/databroker/src/grpc/kuksa_val_v2/val.rs#L502

[erikbosch]

That seems to be true. But we do not care about filter at all right? I thought we used a different approach there as the names root and filter seems to imply something else.

As it is implemented today we should better just have a single field and call it path, or?

In the description we say that root shall be a root branch, but in all test cases we using paths to a signal, like "test.datapoint1".

// List metadata of signals matching the request.
  //
  // Returns (GRPC error code):
  //   NOT_FOUND if the specified root branch does not exist.
  //   UNAUTHENTICATED if no credentials provided or credentials has expired
  //   INVALID_ARGUMENT if the provided path or wildcard is wrong.

So NOT_FOUND actually is returned if there are no matching entities. And most of the examples in https://github.com/eclipse-kuksa/kuksa-databroker/blob/main/doc/wildcard_matching.md has nothing to with a root branch.

So what shall we do - adapt Proto definition to implementation?

FYI @lukasmittag @argerus

[erikbosch]

See #106

We need to align what to do short-term (for next release) as well as long term for ListMetadata.

Doing as little as possible is one option - i.e. just adding a comment "Please do not use" in the *.proto files and documentation.

[erikbosch]

I tried to add some text both explaining how it works today but also a remark that it may change

[rafaeling]

Looks good to me.

[argerus]

sdv.databroker.v1 does not support getting or subscribing to a "target value". And (hence) when it comes to supporting actuation of VSS signals, it's behaviour is more in line with actuate and kuksa.val.v2.

Changes addressed