[cpprestsdk] Update Boost fix-asio-error.patch

[c72578]

• Fix the following error in

  cpprestsdk-2.10.19/Release/tests/functional/pplx/pplx_test/pplx_op_test.cpp:60:27:
  error:
  ‘class boost::asio::io_context’ has no member named ‘post’
   60 |         m_pool->service().post([=]() -> void { proc(param); });
      |                           ^~~~

• Run ./vcpkg x-add-version --all

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version.
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

[BillyONeal]

As this error is reported only in test code can it be fixed to just disable the tests instead?

[c72578]

As this error is reported only in test code can it be fixed to just disable the tests instead?

No, this would not fix the error, only circumvent it.

[BillyONeal]

As this error is reported only in test code can it be fixed to just disable the tests instead?

No, this would not fix the error, only circumvent it.

It does fix the error and would be consistent with our maintainer guide https://learn.microsoft.com/vcpkg/contributing/maintainer-guide#do-not-build-testsdocsexamples-by-default

vcpkg patches are intended to be the minimum possible change that would unblock users, consistent with https://learn.microsoft.com/vcpkg/contributing/maintainer-guide#patching ; and a build system edit is always better than a product code edit in terms of being closer to 'our table'. Patches applied in vcpkg are not intended to be a way to resurrect abandonware; if a project is abandoned and product code changes are necessary to keep it functional we remove the project from the curated registry and do not become effective new upstream maintainers.

As for "cpprestsdk is a bit of a special case given that several vcpkg maintainers were once cpprestsdk maintainers" that was previously litigated in #42678 so I'm not going to go there again.