Postgres function ambiguity issue after upgrade

There was a recent issue of ambiguous function call in Postgres database caused by this change !525 (ebca8642) In essence the newly added function app_create_context had the same signature as the old one that was being removed when called without optional parameters:

haf_block_log> select app_create_context('bob', 'bob');
function app_create_context(unknown, unknown) is not unique
LINE 1: select app_create_context('bob', 'bob')
               ^
HINT:  Could not choose a best candidate function. You might need to add explicit type casts.

That's because the old function was not dropped and was still present in the database after upgrade. This is very easy mistake to do, because it might not reproduce in local development when recreating the whole database.

The possible solutions:

1. Do not use function/procedure overloads and always add DROP FUNCTION for every CREATE FUNCTION and DROP PROCEDURE for each CREATE PROCEDURE. This will remove any possible ambiguity.

E.g.

DROP FUNCTION IF EXISTS foo;
CREATE FUNCTION foo ...

I like this approach, because it is simple change. It is hard to enforce though, but I think we should be able to create a linter rule that helps with that.

2. Always drop all functions in hive schema on upgrade and then re-create dropped functions.

   1. There are some auto-generated functions created at context registration. Those could be moved out of hive to some other schema. That way, hive schema would only contain functions that are safe to drop.

   This is a bigger change than 1. but it has the advantage of no need for any enforcement. Once applied, hive schema should be free of any ambiguities. The new schema is not though (but it only contains auto-generated functions).

   2. Alternatively we could drop only particular set of functions on upgrade that are known to be safe to drop. Or only drop functions matching given same pattern.

   This would be hard to enforce and require maintenance.

IMO we should go with either 1 or 2.1.

As for now we decided to stay all runtime code in hive schema, move tables to hive_data schema, add separated chemas for triggers functions and state providers. It means whole hive schema could be dropped before the update