Methods without @Property got invoked during serialization

I'm looking at version 2.3 but I think the behavior holds for the lastest version.

The following code is based on https://github.com/hyperledger/fabric-samples/tree/main/asset-transfer-basic/chaincode-java.

```java
@DataType
public class Sale {
public String getName() {
System.out.println("getName");
return getName();
}
}

@Contract
public final class AssetTransfer implements ContractInterface {

@Transaction(intent = Transaction.TYPE.EVALUATE)
public Sale getSale(final Context ctx) {
return new Sale();
}
}
```

I deliberately wrote a recursion but it should be a factor because this method is not marked with @Property.

After I call `peer chaincode query -C mychannel -n basic -c '{"Args":["getSale"]}'`, I then check the docker logs by running (zsh)

```zsh
docker logs $(docker ps -n 1 --filter 'name=dev-peer0.org1' --format '{{.ID}}') |& vim -
```

I see a huge number of output "getName", which indicates getName() is called although it's not marked with @Property.

In this example code, there is nothing going wrong. But if the method returns an object that requires another serialization or has cyclic reference, this unexpected call is very likely to cause uncatched StackOverflowError or other errors.

This log is from my real project. You can see I eventually get
```
thread[fabric-txinvoke:3,5,main] 05:37:40:138 severe org.hyperledger.fabric.logger error nulljava.lang.stackoverflowerror
```
[infinite-call.log](https://github.com/hyperledger/fabric-chaincode-java/files/8203543/infinite-call.log)

I feel I should use the magic word "@JSONPropertyIgnore" on getName().

This secret word didn't appear on https://hyperledger-fabric.readthedocs.io/en/latest/search.html?q=JSONPropertyIgnore&check_keywords=yes nor this repo.

Should we add `@JSONPropertyIgnore` somewhere?

Reproduce the behavior using the asset-transfer-basic/chaincode-java Sale example and the getSale entry point, then run the documented peer chaincode query while checking the peer logs. Trace the Java serialization path to determine why an unannotated getName method is invoked. Done means the behavior is corrected or the required annotation and its usage are clearly documented, with a regression test if the repository provides a suitable test location.

Written by the indexing model from the issue text.