Improve line folding and serialization performance

[axunonb]

• Update line folding to use StringBuilder and ArrayPool for better performance and memory efficiency.
• Ensure compliance with RFC 5545 by handling multi-byte characters correctly when folding lines
• Add System.Buffers package for netstandard2.0 target framework.

Resolves #693

[axunonb]

Reducing cognitive complexity by splitting up this method

[minichma]

Basically LGTM. One finding would be that I think it would be desirable for a serializer to treat the values it operates on as immutable but we modify the TZID property of the period list. Not sure we can change that. I know that's not a new pattern though.

[axunonb]

Excellent, thanks for pointing this out.
The mentioned code became fully redundant with #684: All timezones of a PeriodList are always the same, and there's nothing left to care for in PropertySerializer when serializing 👍

ical.net/Ical.Net/Serialization/DataTypes/PeriodListSerializer.cs

Lines 42 to 46 in 366b705

	// Set TzId before ValueType, so that it serializes first
	if (firstPeriod != null && !string.IsNullOrEmpty(firstPeriod.TzId) && firstPeriod.TzId != "UTC")
	{
	periodList.Parameters.Set("TZID", periodList[0].TzId);
	}

[minichma]

The mentioned code became fully redundant with #684: All timezones of a PeriodList are always the same, and there's nothing left to care for in PropertySerializer when serializing 👍

Wonderful! It would be good at some point to get rid of the redundant data we have in this regard now. I.e. we have the Properties collection which can hold a TZID proprety, as well as the explicit TzId fields in Period.StartDate.

[minichma]

LGTM, just another very small comment

[minichma]

I see the performance optimization the usage of the ArrayPool could bring but I would usually try to avoid using a global pool here. It increases complexity and could have unexpected side effects. Had similar situations (in other languages though) where some memory sanitizer suddenly complained that the globally allocated memory changed after calling a certain method just because of some global cache. This might not be the case here but given the quite small effect we can expect from the optimization (compared to just allocating a new array) and given the fact that we don't know how/where users of the lib will will use it, I would rather avoid it.

Question is, whether its needed at all. Why not directly append to the result?

[axunonb]

KISS, replaced it

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud