Libuv pod and event engine core test suite setup for iOS/ObjC

[dennycd]

Initial scaffolding to bring in libuv and event engine core test structure for iOS/ObjC stack. Change summary below:

1. Introduce new podspec for libuv-grpc

Creating new podspec for bringing in libuv on iOS/Objc.

• Libuv-gRPC.podspec: new podspec for libuv. Published as Libuv-gRPC on cocoapod trunk.
• gRPC-Core.podspec: adding libuv as dependency lib for gRPC-Core pod

Reasons for the change:

• A separate libuv pod helps modularize gRPC-Core's 3p dependencies on iOS stack. Instead of aggregating all 3p source through gRPC-Core, here we packaging libuv under a standalone pod module
• OSS Community reuse of Libuv-gRPC for iOS

2. Introducing iOS Core Test pod setup and adding event engine timer test suite

• Setting up a new iOS test pod (CoreTests) dedicated for unit testing c-core from within iOS build chain & runtime.
  • In the future, CoreTests will be hosting other C-Core/EE test coverage on iOS. These should be light-weight test logic aiming at verifying c-core's functions on iOS.

---

A few follow up todos after this initial step

• Auto-generate libuv source & headers via buildgen script using template
  • Currently as 1st step, we hard-coded libuv source in podspec. Ideally these are pulled from libuv.BUILD rules and tunneled through its template files and auto-populated (alongside build flags) via buildgen script. This reduce maintenance overhead.
• Adding test coverage for EE's timer implementation into EventEngineTimerTests
  • also look at how we can have better reuse of existing test logic from c-core. One possibility is to expose EE's test logic via test util and call from iOS test (similar to cronet e2e test)
• More follow up test coverage for other EE // libuv components

[dennycd]

@HannahShiSFB

[drfloob]

Great to see progress made on libuv/iOS!

The binary size diff test is broken due to missing libuv dependencies, so I think there's still a piece missing here.

Sat Oct  2 00:21:45 PDT 2021 - In file included from /Volumes/BuildData/tmpfs/src/github/grpc/src/objective-c/examples/Sample/Pods/Libuv-gRPC/src/uv-common.c:22:
Sat Oct  2 00:21:45 PDT 2021 - /Volumes/BuildData/tmpfs/src/github/grpc/src/objective-c/examples/Sample/Pods/Libuv-gRPC/include/uv.h:53:12: fatal error: 'uv/uv/errno.h' file not found
Sat Oct  2 00:21:45 PDT 2021 -   #include <uv/uv/errno.h>
Sat Oct  2 00:21:45 PDT 2021 -            ^~~~~~~~~~~~~~~
Sat Oct  2 00:21:45 PDT 2021 - /Volumes/BuildData/tmpfs/src/github/grpc/src/objective-c/examples/Sample/Pods/Libuv-gRPC/include/uv.h:53:12: note: did not find header 'uv/errno.h' in framework 'uv' (loaded from '/Volumes/BuildData/tmpfs/src/github/grpc/src/objective-c/examples/Sample/Build/Build/Build/Products/Release-iphoneos/Libuv-gRPC')

Also, it looks like the sanity check is failing on a need for a clang_format run.

[dennycd]

point to a landing page on cocoapod trunk

[sampajano]

Thanks so much for the change, Denny (And the detailed in person review)!! Great step to unblock the EventEngine migration!

My only major comment is that while Podspec looks to be a nice way to manage sub-dependencies, the way it's done right now does seem to involve some duplicate maintenance overhead (on top of maintaining the build for core, e.g. specifying all the headers / files / build flags).

Maybe you could document a bit more on why you chose this approach (and maybe why it's superior) and how going forward we could minimize its maintenance cost.

Thanks!! :)

(btw It'd also be nice if some other build expert can take a look at this PR too :))

[dennycd]

all build break fixed

[drfloob]

I'm learning a bit about cocoapods tonight ... do you intend to maintain a public, separately-installable libuv target? I'm not really sure it's our place to do so, especially given that we might not end up using it for iOS ourselves in gRPC (worst case), and that a handful of obj-c/swift platforms are not officially supported by libuv. CC @nicolasnoble.

https://cocoapods.org/pods/Libuv-gRPC

Also, it appears the sanity checks are still failing, possibly from changes in master since you last merged?

[drfloob]

Chatting offline, everything SGTM! Thanks Denny!

Summary: we should look into the possibility of making the libuv-grpc cocoapod private if possible, but I don't want to block this PR if not.

[sampajano]

Chatting offline, everything SGTM! Thanks Denny!

Summary: we should look into the possibility of making the libuv-grpc cocoapod private if possible, but I don't want to block this PR if not.

Yeah on a similar note.. i kind of prefer how some of our other pods are named, e.g. gRPC-RxLibrary & gRPC-ProtoRPC, as opposed to Libuv-gRPC and BoringSSL-GRPC, as the former seems to be more eco-friendly to the overall cocoapods namespace (unless we really have intentions for 3rd party users to depend on them) :)

[dennycd]

Thanks AJ. We will spin out a separate task to move gRPC-only dependency pods into private. For the current PR, we will mark it as intended for gRPC only usage.