Avoid leaked semaphores

[troyraen]

Background

We have been encountering "leaked semaphore" warnings occasionally. It's difficult to track down exactly where this is coming from, but I believe we are experiencing issue python/cpython#90549 which reports a bug in python's multiprocessing stemming from the combined use of global resources and "spawning" new processes*. We have been using "spawn" (over the default "fork") because it is thread-safe, which is required for pd.read_parquet, which was being used by ZTF_get_lightcurve. This PR replaces pd.read_parquet with a pyarrow method and switches multiprocessing to "fork".

*Note: A fix has been backported to python>=3.10. I'm still getting the warning using 3.10, but I can't tell if I'm using a version that includes the backport.

Included Changes

• Remove calls to mp.set_start_method("spawn").
• Replace pd.read_parquet(..) with pyarrow.parquet.read_table(..).to_pandas().
• Replace filesystem handler s3fs with pyarrow.fs. This is not strictly necessary, but it's convenient to just use pyarrow for everything. Since no other modules depend on s3fs, I have also removed it from the explicit requirements for light curves. Please let me know if you would prefer to keep it (maybe @bsipocz).

[bsipocz]

Replace filesystem handler s3fs with pyarrow.fs. This is not strictly necessary, but it's convenient to just use pyarrow for everything. Since no other modules depend on s3fs, I have also removed it from the explicit requirements for light curves. Please let me know if you would prefer to keep it (maybe @bsipocz).

I suspect it will be installed anyway as an astropy/pyvo/astroquery dependency, but not directly rely on it sounds good to me, it's always good to keep the dependency footprint to the minimum.

[bsipocz]

*Note: A fix has been backported to python>=3.10. I'm still getting the warning using 3.10, but I can't tell if I'm using a version that includes the backport.

If we can, it would be good to move onto 3.11 or 3.12, so no need to sort out older warnings.

[troyraen]

I've run several tests and haven't seen a leaked semaphore warning. Since the warning did not occur every time, I can't be positive that this fixes it. @jkrick can you run a test or two and see if you get the warning? If you don't, then I think this is ready to merge.

[bsipocz]

All things equal, any code changes with negative net lines are good, let alone when they also remove a dependency.

[jkrick]

I ran it with 1,000 and 10,000 sources on the SMCE and both ran successfully.