Use JMeterProperty#intValue for loop count directly

[FSchumacher]

Description

This will get rid of the roundtrip over a String in case, the prop is already an IntegerProperty.

Motivation and Context

Came up in the discussion about #5875 and looks like an easy first fix.

How Has This Been Tested?

Should be covered by the unit tests already

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code follows the code style of this project.

[vlsi]

Could you please fix the other getStringValue->parseInt cases?
For instance: ThroughputController, JMSSampler.

[FSchumacher]

I looked at ThroughputController and it is not easily fixed by using this approach, as it relies on a different default value.
The AbstractProperty#getFloatValue catches NumberFormatExceptions and returns 0. So, using it directly would lead to a different default value in case of a broken value.
How did you search for those occurrences? I had to look a bit longer to find line 600 in JMSSampler, but there are surely more? Line 600 is a good candidate to replace, so I will extend this PR with it. Feel free, to push any changes, too.

[vlsi]

I used "find usages" for getStringValue, and then I filtered the entries that parse the result as integer.

I think this looks like

jmeter/src/components/src/main/java/org/apache/jmeter/control/ThroughputController.java

Lines 129 to 131 in b6d11d7

	String valueString = prop.getStringValue();
	try {
	retVal = Integer.parseInt(valueString);

is pretty much like "get property as int" to me.

I'm not sure what to do with getFloatValue, however, it looks like getStringValue + parseFloat should also be replaced with getFloatValue.

[FSchumacher]

If you look at that method, you will see, that it assumes a default value of 1 and uses that in case of a NumberFormatException. If we use JMeterProperty#getIntValue we would never get that exception, but a default value of 0.