Sync user data from Radiance in Flutter

[atavism]

Resolves https://github.com/getlantern/engineering/issues/2944

This PR replaces Flutter local DB/local storage reads for user, plans, split-tunneling, private servers, and selected server location with Riverpod providers backed by lantern-core/Radiance APIs (with Go-side on-disk caching)

[jigar-f]

@atavism I think this pretty big change, did we remove obejctbox completly? I thought we were just removing private server stuff.

• With this change, now every time we need adda new local state, we need to add an ffi method and a platform channel against it, before we just did with object box, only one method.
• With this, now it goes to flutter->ffi/platfomchannel-> go aginest flutter->done

Correct if I'm wrong, I have not looked in detail.

[atavism]

@jigar-f Yes, I went ahead and fully removed ObjectBox in this PR. If Radiance is our source of truth for persistent state (user, selected server, split tunneling, etc.), I think we’re better off not keeping a separate Flutter DB. I get the concern about extra FFI/platform-channel calls, but we can keep the surface area small with a few get/set endpoints (and core caching) instead of duplicating state...Does that sound reasonable?

[atavism]

For instance, we could expose getAppState / updateAppState instead of one API per field

[jigar-f]

Agreed, Radiance should definitely be the source for VPN-related functionality. That said, I don’t think Radiance needs to care whether a user has a plan or not, or whether the user is shown an intro, etc. That logic can probably live elsewhere — though I don’t have a strong opinion against it.

I think we should take the time to test everything thoroughly and make sure all flows are working as expected before merging.
Did you get a chance to test all flows, especially auth and purchase?